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Évnyitó akciónk keretében valamennyi Mos 
képzésünkön még tavalyi áron vehet részt!" 


Néhány képzés ízelítőül az év elejéről, a teljes kínálatért kérjük, Í 
keresse fel internetoldalunkat! ; 


e Windows 2003 üzemeltetés (2273) - január 29-február 2., március 5-9. 

" Windows 2003 Active Directory (2279) - január 29-február 2., február 19-23. 
" Windows 2003 biztonság és PKI (2830) - január 29-február 2., március 19-23. 
e Windows 2003 hálózatüzemeltetés (2276/77) - február 26-március 2. 

e Windows 2003 Cluster szolgáltatások (2087) - március 12-14. 

e Windows 2003 hálózatrendszertervezés (2278) - március 26-30. 

e Windows XP terméktámogató (MCDST) képzés - február 5-9., március 19-23. 
e SOL Server 2000/2005 alapok (2071) - február 5-6. 

e SOL Server 2005 programozás (2779) - február 7-9. 

e SOL Server 2000 programozás (2073) - február 19-23. 

e Exchange Server 2003 üzemeltetés (2400) - február 19-23. 

e Microsoft CRM 3.0 alkalmazások használata (8521-24) - február 15-17. 

e Ct és Visual Studio 2005 technológiai alapismeretek (2609E) - március 5-9. 
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Kedvezményes Microsoft mérnök képzéssorozatok (MCSA, MCSE, MCTS, MCITP). 


A 2007-es év Microsoft tanfolyami újdonságai 


e. Windows Vista 


e SOL Server 2005 üzleti intelligencia rendszerek 
ge e Exchange Server 2007 


ee A Mi tudásunk e SharePoint Services 3.0 


CiZ oO AN sike re és SharePoint Portal Server 2007 


Mt ISA Server 2006 


XAz akció a 2007. március 1-ig megrendelt tanfolyamok esetében érvényes. Az akció 
részleteivel és 2007-ben megjelenő új képzéseinkkel és szolgáltatásainkkal kapcsolatosan 16 
internetoldalunkon találhat további információt. A képzésekre a jogszabályok szerint Ti 

igénybe vehető a szakképzési hozzájárulás és felhasználható az SA oktatási utalvány. 


Telefon: 203-0304/4122 m. 


www.szamalk.hu/jtisza 
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KEZDJÜK 
FRISSEN 
AZ ÚJ ÉVET! 


Elkészült a Windows Vista, 
az Office 2007 Rendszer 


és az Exchange Server 2007. 








z új Windows-, Office- és Exchange-verziók 2007 első felétől lesznek elérhetők a felhasz- 

nálók és a vállalatok számára, érdemes tehát minél hamarabb megismerkedni velük. 

Nem egyszerűen újabb verziók megjelenésével van ugyanis dolgunk: ezek a szoftverek 
igyekeznek újraértelmezni az informatikát, és azt a végfelhasználók kezébe adni, megkönnyítve 
a mindennapi munkavégzést. Amellett, hogy számtalan esetben okosabbak, jobbak elődeik: 
nél, ezek az új technológiák képezik majd a következő évtizedben megjelenő további szoftverek 
alapját is. Nagyon sok változásról beszélünk, és ezek közül néhánynak lehet, hogy még nem lát 
juk értelmét, fontosságát - de idővel össze fog állni a kép. 

Az elmúlt egy évben rengeteget foglalkoztunk a Windows Vista és a 2007-es Office Rendszer 
újdonságaival mind a Magazinban, mind eseményeken, de ehhez képest lényegesen kevesebbet 
- szinte semmit nem - szóltunk az új Exchange Serverről, pedig rendszergazda-szemmel nézve 
ez is legalább annyira fontos terület. Az Exchange Server már évek óta biztosítja a vállalatok 
számára talán legfontosabb csoportmunka-funkció - igen, ez a levelezés - zavartalan működé- 
sét. Most látni fogjuk, hogy az Exchange túllépett régi önmagán. Teljesen újratervezték a szoft 
vert, sokkal modulárisabb lett, és szorosabban integrálódik a többi szervermegoldással is, vala- 
mint lényegesen több felhasználót és nagyobb terhelést képes kezelni - hála a 64 bitnek. 

A fejlődésnek természetesen még nincs vége: a következő jelentősebb áttörést a System 
Center rendszermenedzsmenttermékcsalád tavaszi megjelenése és a , Longhorn" Server év végi 


érkezése jelenti majd. 
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kívüli kliensek 





Az Exchange Server 2007 architektúrája 
(Petrényi József) 
Az Exchange Server 2007 számtalan apró elemből épül fel. 


Ezeket az apró funkcionális elemeket csoportokba rendezték 





- és a csoportokat szerepkörnek nevezték el 6. oldal 
A megújult Exchange Management Console 

(Subicz Péter) 

Az új Exchanger-et fejlesztő csapat nagy hangsúlyt helyezett 

az új Management Console kidolgozására is - az eredmény önmagáért beszél 12. oldal 


Kitekintés az Outlook 2007-re 

(Budai Péter) 

Az e számunkat uraló Exchange Server 2007 mellett 

a Microsoft Office-ban található Outlook-kliens 2007-es változata is 


szolgál kellemes meglepetésekkel 15. oldal 


Exchange Management Shell 
(Szabó Dávid) 
Az Exchange Server 2007 üzemeltetéssel kapcsolatos újdonságai közül talán 


a PowerShellparancsgyűjtemény a legnagyobb áttörés 


az Exchange 2003-hoz képest 16. oldal 


Tervezés és telepítés 
(Petrényi József) 
Alapos tervezésnek kell megelőznie a tényleges telepítést 


18. oldal 


- ezzel később rengeteg időt és energiát spórolunk meg magunknak 


Exchange Server 2007: magas rendelkezésre állás 
(Ország Tamás) 
Cikkünkben az Exchange Server 2007 hibatűrését fokozó 


- online és offline - megoldásokat tekintjük át 


23. oldal 


Mikor váltsunk 64 bitre? 

(Budai Péter) 

Rengeteg a tévhit a 64 bites rendszerekkel kapcsolatban. 

Például ha ma valaki 64 bites hardvert vásárol, 

26. oldal 


rögtön 64 bites operációs rendszert tesz rá. Biztosan jó döntés ez? 


Microsoft TechNet 


Biztonság 


Tüzetes ellenőrzések 
(Kelemen László) 


Írásunkban az Exchange-nek azokat 


a biztonsági vonatkozásait tekintjük át, 


amelyek az internetes kellemetlenségek 


és fenyegetések, azaz a levélszemét és 


a kártevők elleni közvetlen védelmet 


szolgálják 





Scripting 


30. oldal 


Powershell-scriptek a gyakorlatban 


(Fóti Marcell) 


Ezúttal picit behatóbban elemezzük 


a CommandLeteket, valamint 
megismerkedünk az objektumok 
feldolgozásának kilenc fontos 


parancsával 


34. oldal 

















Alkalmazásplatform 


Készen kapott CRM 

(Kovács László-Wentzel István) 

Kinek és mire jó a Microsoft Dynamics 
CRM, és hogyan mérhető az üzleti 
teljesítmény az új, kiszolgáló alapú 
mutatószámrendszer és teljesítménymutató 


alkalmazás, a Business Scorecard Manager 


2005 használatával? 37. oldal 


LINÓ 
(Nagy levente) 

Ha valaki készített már objektumorientált 
alkalmazást, amelyik használt adatbázist, 
esetleg XML-dokumentumokat, az tudja, 
hogy mennyire különbözik az egyes 
területek hozzáállása az adatok tárolásához, 


eléréséhez, a vezérléshez 40. oldal 
EME EZTET] 


Konkurenciakezelés 


az SOL Server 2005-ben 

(Kovács Zoltán) 

Az SOL Server 2005 fejlesztői régi 
adósságot törlesztettek: megvalósították 
a versenytársaknál már több mint egy 
évtizede sikerrel alkalmazott optimista 


konkurenciakezelési modellt. — 44. oldal 
EESSEEEE ESETE sezesssszssgi] 





; Az SMTP-szerver SMTP-munkafolyamatot kezdeményez 











Közösség 

A Microsoft Magyarország bemutatása 
(Budai Péter) 

Bemutatkozik egy olyan vállalat, 

ahol sokan szeretnek dolgozni 

- és sokat is tesznek a sikerekért 49. oldal 





ett fdc ] Scope: futureinc.com 


and Settingsvádmninistrator?add-PublicFolderClientPernissi 
MTeszt Nyilvános MappaMAálmappa" -user "Teszt user" -accessrights Create 


LEE TATT TTL nÉS 
dentity " 
61 Ti 


Identity User hIHTZÉSÉS sRights 


MTeszt Nyilvános Mappax... FENE ree com/Teszt user AB ZET ETT 


a AAL z lési and ,Settings Mi L(Uhtth ési hétbe get-PublicFolderClientPernmissi 
FENÉT NTeszt Nyilvános MappaMálmappa 


AccessRights 
s MappaXx... Default 
s MappaX... futureinc.com/Teszt user 
s MappaX... futureinc.com/Users/Ádn. . 
s MappaX... Anonymous 
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AdventureWorks CRM Analyzer 
Analytics from Mcrosott Oynamucs CRM 


CAN Analyzer KPIs 
4 0 9 Vr 
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E CÍMLAPON 


Az EXCHANGE 





SERVER 2007 
ARCHITEKTUÚRÁJA 


Lényeges változások történtek az Exchange Server 2007 


telépítésében — ezektől azonban nem szabad megijedni, 


mind hasznunkra válik majd. 


z Exchange Server 2007 számtalan apró elemből épül fel. Ezeket az apró funkcioná- 
lis elemeket csoportokba rendezték - és a csoportokat szerepbkörnek nevezték el. Egy 
Exchangescszerveralkalmazás szerepkörökből áll össze, maga az Exchange-organizáció pe- 
dig az egyes szerepköröket megvalósító Exchange-szerverekből. 
Ha az architektúrát akarjuk körbejárni, akkor először az egyes szerepköröket kell alaposan 
szemügyre vennünk, majd beszélnünk kell a köztük lévő kapcsolatról. 


Hogy maguk a szerepkörök ne csak úgy lebegjenek a levegőben, 


ciójuk elé valamilyen más gyártótól származó 
smarthostot. Ez elvégezte a piszkos munka 
nagy részét: szűrte a spameket, gyapálta a ví- 
rusokat és a spyware-eket. 

Ebben a megközelítésben a fő szempont az 


volt, hogy az ember leválasztotta a mocskos 





Más SMTP 


érdemes lesz rendszeresen vissza-visszatérni az I. ábrához. 
eye dd 


Itt látható vázlatosan, hogyan is épül fel egy teljes Exchange 
Server 2007-organizáció, milyen kapcsolatban állnak egymással az 
egyes szerepkörök. 

De még mielőtt belecsapnánk a közepébe, nem árt letisztázni, mi- 
lyen is a viszony a fizikai gép formájában megjelenő Exchange-szer- 
ver és az egyes szerepkörök között. 

Vadregényes. 

Az öt szerepkör közül négy minden további nélkül bezsúfolható 
egy szerverbe. (Az 1. ábrán is látható, hogy az Edge Iransport funk 
ció tűzfal mögött van - ezt azért nem lenne egyszerű megvalósítani 


egy belső hálóra rakott mailbox-szerveren.) Mindemellett semmi Vállalati hálózaton 
KOVTTASA 





akadálya nincs annak sem, hogy mindegyik funkció fizikailag is 





Vállalati hálózat 


Routolás rázisedl 








külön vasra kerüljön. Mindig az adott szituáció szabja meg, hogy a 1. ábra. Az Exchange-organizáció architektúrája 


megvalósítás milyen kompromisszumok szerint történjen meg. 


Nézzük részletesen az egyes szerepköröket! 


Az Edge Transport szerepkör 
Bóklászik a levél az interneten, végül boldogan megtalálja a dessungelben cégünk MX rekordját 
és fáradtan, de alapvetően elégedetten be is esik a megadott szerverre. 

Valljuk be őszintén, ez manapság a legritkább esetben Exchange-szerver. Nem mindig volt 


ez így, de amióta annyira koszos lett az internet, egyre többen pakoltak az Exchange-organizá- 


[4 


munkát az éles organizációról. Sőt, magát a 
smarthostot is ki lehetett tenni az előszobába. 

Tulajdonképpen ugyanezt a filozófiát való- 
sítja meg az Edge Iransport szerepkör. Például 
azt állítja magáról, hogy olyan Exchange-szer- 
ver, amelyik nem tagja az organizációnak. 


Sőt: nem tagja az Active Directorynak sem! 


Microsoft TechNet 
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Azért ez így már elég érdekes. Gyakorlatilag 
kaptunk egy olyan Exchange-szervert, ame- 
lyiknek semmi Exchange jellege sincs: műkö- 
dik rajta egy SMI P-motor, a motorra szorgos 
ügynökök serege kapcsolódik rá, mindegyik 
egyfajta szűrőként funkcionálva, teleaggathat 
juk mindenféle szabályokkal - és ennyi. Mitől 
lesz ez mégis több, mint egy külső gyártó által 
megvalósított megoldás? Attól, hogy lesz raj- 
ta egy LDAPszerver, amelyet össze tudunk 


lőni a Microsoft Active Dt 


CXCNANYE MANAgYEINETT LUTT 


Először vegyük szemügyre az ügynököket. 
Láthatjuk a grafikus felületen, van néhány. 
Aki azt hiszi, hogy ennyi a készlet, ezekkel 
kell dolgozni, az téved. Fura módon nem 
minden ügynököt vezettek ki a felületre. 

Ezeket látjuk (2. ábra) a grafikus konzolon. 

És ezeket látjuk (3. ábra), ha a gettransport 
agent paranccsal lekérjük az ügynöklistát az 
Exchange Management Shell és a Windows 
PowerShell segítségével. 


Suua .-m 11IJ4 





ml f . A Action Help 
rectoryjával - és innentől ke 





az Exchangescszerver teljesen (9 maesseei 


(én Toolbox 


úgy fog viselkedni, mintha 
benne lenne a címtárban, 
annak ellenére, hogy valójá- 


ban nincs benne. 


; get; Anti-spam ] Receive Connectors ] Send Connectors ] Transport Rules ] 6) Disable 
A Microsoft önállóan I Hansa 
57 Content Filtering 
megvalósított LDAPszerve- Hi A ÜL SG ti (8 Hap 
B 5 971P Block List Enabled 
re az Active Directory ÁAp- 971P Block List Providers Enabled 
kk 57 Recipient Filtering Enabled 
, . sells 97 Sender Filterii Enabled 
plication Mode, röviden Beee KT Enabled 
97 Sender Reputation 
ADAM névre hallgat (amit 
épp most keresztelnek át 
; ; $ 
Active . Directory Light aira a Iz I NEY 


weight Directory Services- 2. ábra. Antispam 


AD/LDS-re). 


Gyakorlatilag egy kicsi, önálló címtár, ame- 


Te, [vagyis 
lyik teljesen hasonlóan működik, mint a 
nagytestvére, ugyanúgy ADSIEdittel, LDP- 
vel és ldifde/csvde segédprogramokkal ke- 
zelhető, mint a nagy címtár - de nem olvad 
bele annak partícióiba, önálló, saját adatbá- 
zisa van. Mivel mindkét címtár Microsoft 
fejlesztés, és működésüket tekintve nagyon 
is hasonlítanak egymáshoz, a szinkronizá- 
ciójuk sem okozhat különösebb problémát. 

(Megjegyzés: akkor is ADAM-AD szinkroni- 

zálás történik, ha az Edge Iransport számító- 

gépet beléptetjük a tartományba.) 

Magát a szinkronizációt az úgynevezett 
EdgeSync szolgáltatás fogja megvalósítani 
- ez a nevével ellentétben a Hub Iransport 
szervereken fut. 

Az Edge Iransport szerepkör alapvetően 
három csoport tevékenységéből áll össze: 

a az egyik a levéltovábbító mechanizmus, 
amely SMTP ugyan, de teljesen el van rejt 
ve a rendszergazda elől; 

n rendelkezésünkre áll egy sereg ügynök, ezek 
különböző apró feladatokra harapnak; 

a végül kapunk egy szabályrendszert is. 

A két utóbbira egyaránt vonatkozik, hogy 
egyszerre látnak el higiéniás jellegű, illetve 


levéltovábbítási funkciókat is. 
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5. Edge Transport 


(2 Help 
xch2k7edge 
Properties 


9 objects tsz " 
Recipient Filtering 














-ügynökök a grafikus felületen 


Ha a két képet összehasonlítjuk, feltűnhet, 
hogy a grafikus felületen akad néhány olyan 
elem, amelyik tulajdonképpen nem is ügynök 
(például IP Allow List), ezzel szemben alul ta- 
lálunk néhány olyan ügynököt, amelyet nem 
tudunk konfigurálni a konzolból (például 
Address rewriting-ügynökök). Mindez nem 
véletlen. Már a korábbi Exchange-verziókban 


is jelen volt az a tendencia, hogy az igazán hú- 


EN s NR 

Természetesen nem feltétlenül kell ezt a 
szerepkört telepítenünk. A külső gyártók esz- 
közei is megfelelőek lehetnek, de van egy 
olyan terület, ahol azért az Edge Iransport 
szerver többet tud: ez a címtár-szinkronizá- 
ció. Habár ma már egyre több helyen konfti 
gurálható LDAPlekérdezés a címtár felé, de 
az ADAM-AD szinkronizácó emellé plusz 
összhangot is biztosít a smarthost és a cím- 
tár között. 

Nemcsak a postafiókokhoz rendelt e-mail 
címeket adja át, hanem például átküldi a cím- 
tár konfigurációs névteréből az Exchange-to- 
pológiárai vonatkozó "információkat "a" Elub 


Iransport szerverek elhelyezkedéséről. 


A Hub Transport szerepkör 
Képzeletbeli levelünk a Hub Iransport sze- 
repkört birtokló Exchange-szerverre került. 

Amikor először találkozunk a névvel, egy- 
értelműnek látszik: igen, ez foglalkozik a link 
state tábla kezelésével, azaz az e-mail routolá- 
sával. Tovább olvasva azonban nem kis meg- 
lepetéssel észlelhetjük, hogy az Exchange 
Server 2007-ben nem lesz link state tábla. Az 
egész, gyönyörűen felépített routolási rend- 
szert a Routing Master funkcióval egyetem- 
ben kidobták a rendszerből. 

Néha bizony úgy tűnik, az Exhange fejlődé- 
se nagyrészt kidobásból áll. (Persze nem egé- 
szen erről van szó, általában az Exchange-ben 
bevált technikák köszönnek vissza az operá- 
ciós rendszer szintjén - és emiatt lesz végül 
felesleges az Exchange-ben egyedileg megva- 
lósított változat.) Most is hasonló folyamat 


játszódott le: volt egyfelől 
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You can also apply the same deleted item retention limits or mailbox retention 1 


ItemRetention 45.88:AA:BB -MailboxRe 


J — egy különálló, link state táb- 
lán alapuló rendszer, és volt 
egy Active Directory hierar- 
chiakezelő rendszer - ez a 


Priority 


Knowledge Consistency 
Checker (KCCO) -, amely a 
telephelyen belüli, illetve te- 
lephelyek közötti replikáció 
topológiáját kezelte. 





A fejlesztők észrevették a 





3. ábra. Ügynökök PowerShell-commandletből 


zós dolgokat elrejtették az 1.0 adminok elől. 
Itt is ugyanerről van szó: ha keményebb, ve- 
szélyesebb dolgokat akarunk csinálni, akkor 
vegyük elő a PowerShellt és világosan mond- 


juk meg, mit is szeretnénk. Csak úgy ne kat 


tintgassunk bele a GUL-ba. 


minták hasonlóságát, és azt 

mondták, miért ne bízzuk 
az emailroutolást az Active Directory topo- 
lógiakezelő metódusaira? Ezzel tulajdonkép- 
pen vége is lett a sunyításnak - eddig ugyanis 
megtehettük, hogy bár fizikailag egy telephe- 
lyen voltak az Exchange-szervereink, de még- 


is külön Routing Groupba kerültek. Ennek 


A 
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mostantól vége. Az AD site lesz az Exchange 

Routing alapja is. (Ha belegondolunk, ilyen 

eset általában akkor fordult elő, ha mixed 

módú organizációban kellett különböző ad- 

minisztratív csoportokat létrehoznunk. Itt vi 

SZOL az adminisztratív csoport! togalnaa is 

megszűnik.) 

Próbáljunk hozzászokni a gondolathoz: 
an Nem lesz Exchange Routing Master funk- 

ció. Helyette lesz Active Directory-KCC. 

m Kicsit körülményes lesz a levelezési utak 
súlyozása, azt csak PowerShellben tudjuk 
beállítani (Setadsitelink a parancs neve). 

an Nem lesz RGC - azaz Routing Group 
Connector. Helyette lesz AD Site Link 
Connector. 

Egy kis töprengést azért ez is megér. 
Alapvetően a site-site konnektor lehet [P/ 
RPC vagy SMIP alapú. Alapvetően. De mi 
fog történni, ha egy SMIP site-site konnek- 
tort akarok használni egy SMIP levelezési 
rendszerben? Káosz. Éppen ezért az Exchange 
2007-ben nem támogatott az SMIP alapú 
site-site konnektor (ez újabb szög az SMTP 
site-site konnektor koporsójába - feltéve, 
hogy már korábban nem dobtuk ki korláto- 
zott replikációs képességei miatt). 

Milyen lesz az együttélés az Exchange 2003 
szerverekkel? 

Telepítéskor automatikusan jön létre egy 
Röttas e GrojbaFercas tópbant a lhamozatos 
DWBGZMFDOIONBIR névre 


(Valószínűleg a fejlesztő a kutyájáról nevezte el 


hallgatva. 


a csoportot.) [de kerül bele az összes Exchange 
2007 szerver, és ez a Routing Group fog részt 
venni a kommunikációban - azaz a régi szer- 
verek az új Exchange:-szerverek ilyen arcát fog- 
ják látni. Amennyiben egy világméretű orga- 
nizációban van szerencsénk dolgozni, akkor 
vélhetően nem fogja kielégíteni az igényeinket 
egy olyan megoldás, hogy a tokiói és az alasz- 
kai Exchange 2007-szerverünk ugyanabban 
a Routing Groupban legyen, és a legelőször 
felhúzott szerver legyen közülük a bridge- 
head szerver. Rossz hír: az Exchange 2007- 
ben Routing Group Connectort nem tudunk 
grafikus felületről létrehozni. Jó hír, hogy 
Powershellből igen: a New-RoutingGroup- 
Connector és a SetRoutingGroupConnector 


commandlet lesz a barátunk. 


Különálló Exchange SMTP-szerver 
Tehát nem a Hub Iransport szerver lesz a 


Routing Master az organizációban. Akkor mi 
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is lesz a szerepe? Nos, ez lesz az SMI P-szerver! 
Méghozzá egyedül ebben a szerepkörben lesz 
SVMVP-motor (valamint az Edec Transport 
szerepkörben, amennyiben telepítjük.) 

Kell egy kis idő mindezt megemészteni... 

Nem lesz mindegyik Exchange-szerveren 
SMIP-motor. Ahol lesz, ott viszont egy me- 
nedzselt kódban újraírt, teljesen új SMIP- 
motor fog dübörögni. Az IIS SMITPtszer- 
ver motorja megy a kukába. A szerepkörök 
közötti kommunikációban visszatérünk az 
RPC protokollra. Amennyiben egy Active 


Directory-site-on nem valósítjuk meg a Hub 


vábbítani lehet a leveleket. Természetesen eb- 
be a hálózatba bele tudunk avatkozni trans- 
port rule-ok segítségével - de a belső le- 
velezésnél erre nem lesz szükség, mert a 
megfelelő implicit szabályok automatikusan 
generálódnak majd - beleértve ebbe a Hub 
Iransport és Edge Iransport szerepkörök kö- 
zötti szabályokat is. Az Active Directory-site- 
site konnektorok fizikai kezdő és végpont 
jai az Active Directory-bridgehead szerverek, 
de az Exchange-organizációban a konkrét 
Active Directory-site-ok levelezésért felelős 
Hub Iransport szerepköreit megvalósító szer- 


vereket fogjuk látni. 





e  Achon Miew  Favontes Window Help. 
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Ezaonyita joy van hogy 
külön lesz egy Microsoft 
Exchange Active Directory 
mopology esszolgáltatás sz 
folyamatosan karbantartja, 
hogy melyik Exchange-szer- 
ver melyik Active Directory- 
site-on van. A gyakorlatban 
ez úgy néz ki, hogy minden 
Exchanges-szerverobjektum- 


nak lesz egy olyan tulajdon- 





sága, amelyiknek az értéke 





4. ábra. Site-bejegyzés az Exchange Server-objektumon 


Iransport szerepkört, nem fogunk tudni 
kommunikálni a site-ban elhelyezkedő mail 
boxcszerverekkel. Kizárólag a Hub Iransport 
szerepkörök és az Edge Iransport szerepkö- 
rök fognak egymással SMIP-n kommunikál 
ni. Csak ezeknek a szerepköröknek lesznek 
levelezési sorai (gueue). Értelemszerűen csak 
ezeken a szerepkörökön lehet konfigurálni 
mindent, ami az SMI P-vel kapcsolatos: higié- 
nia, routing, házirendek. 

El lehet meditálni rajta, mennyire kell 
gondolkodá- 


sunkat, a fejünkben lévő sémákat. Kezdve 


majd  megváltoztatnunk a 


olyan apróságokkal, hogy nem fogjuk meg- 
találni a szolgáltatások között a Simple Mail 
Iransport Protocolt - helyette lesz olyan, 
hogy Microsoft Exchange Iransport service. 
Bevégezve azzal, hogy ha a Hub-szerverek 
dolgaslesz cas Toutolás sakkot mieis vant a 
nem sokkal ezelőtt említett AD alapú topoló- 
giával? 

Az, hogy mind a kettő működik. A Hub- 
szerverek ismerik egymást, tudják, hogy me- 
lyik Active Directory-site-on ki - vagy kik - a 
felelősek a levelezésért - azaz tudják, hogy 


melyik az az SMIP:szerver, amelyiknek to- 


mutatja, hol van a konkrét 
szerver. (Ezzel a trükkel le- 
het site-hoz rendelni az Edge Iransport Server 
szerepkört megvalósító szervert is - annak el- 


lenére, hogy bent sincs a címtárban.) 


A transport rule-ok 

Ha már az érdekességeknél járunk, meg lehet 
majd tippelni, hol tárolódnak a transport 
rule-ok. Nem nehéz feladat, nyilván a címtár- 
ban. Ez viszont automatikusan azt is jelenti, 
hogy egy szabály, de hasonlóan egy send con- 
nector sem csak egy szerverre fog vonatkozni, 
hanem az organizáció összes Hub Iransport 
szerverén is meg fog jelenni. 

Érdemes alaposan tanulmányozni az 5. áb- 
rát. Ugye, látjuk? Az organizáció alatti Hub 
Iransport szerepkör alatt fogjuk megtalálni 
az Összes: 

a transport rulett; 
a a journaling beállításokat; 
a a send connectorokat és 


m az összes email address házirendet. 


Házirendek 
Térjünk vissza egy pillantás erejéig az 1. ábrá- 
ra: láthatjuk, hogy a Hub Iransport szerep- 


kör felelősségi köre a routolás és a házirend. 
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A routolást megbeszéltük. Mit takar a házi 
rend? Nos, egyfelől a már szintén említett 
transport rule-okat. Ezek ténylegesen levél 
továbbításra vonatkozó házirendek - és mint 
ilyenek, abszolút újdonságnak számítanak. 

Korábban bármit is akartunk röptében 
csinálni a levéllel, rögtön SMTP event sink-et 
kellett bepattintani az SMIP engine levélfelk 
dolgozási mechanizmusába. Itt viszont bele- 
építettek a termékbe egy jó nagy doboznyi 
építőkockát, amelyből az adminisztrátor meg- 
lehetősen sokféle levéltovábbítási előírást tud 
magának összerakni. 

Szintén a házirend fogalmába tartozik a 
journaling funkció is. Igaz, ilyesmi volt az 
Exchange 2003-ban is, de az új termékben 
kibővült egy kicsit: a régiben csak egy pos- 
tafiókot adhattunk meg, ahová másolatot 
kértünk az összes levélről - most tetszőlege- 
sen szabályozhatjuk a másolandó levelek kö- 
rét, célpontként pedig megadhatunk külső 
SMIP szervert, illetve Sharepoint site-ot. 


Mailbox Server szerepkör 

Képzeletbeli levelünk áthaladt a pályaudvar 
váltóin, lassan meg is érkezik végső helyére, a 
felhasználó postafiókjába. Nézzük, milyen ar- 
chitektúrális változásokat 108 16t tapasztalni 

Nincs többé Recipient Update Service 
(RUS). Kész, megszűnt. Az eredeti szolgálta- 
tás két modulból állt össze: az egyik kikalku- 
lálta a felhasználó e-maikcímeit, a másik mo- 
dul aszinkron szolgáltatásként időnként le- 
futott, detektálta, hogy új postafiók került a 
rendszerbe, és stempliként rányomta az előző 
modul által kikalkulált e-mailcímegyüttest. 

Az Exchange 2007 alatt a második modul 
szűnt meg - és vele együtt ment a levesbe az 
aszinkron stemplizés is. Amikor létrehozunk 
egy új postafiókot, a Recipient Management 
commandlet rögtön rá is teszi az első modul 
által kikalkulált címeket. 

Persze, a világ nem ennyire egyszerű. A 
RUS-nak nem csak ez az egy funkciója léte- 
zett, maga az aszinkron mechanizmus más 
feladatok elvégzésére is lehetőséget adott (pél 
dául címlisták generálására) Az Exchange 
2007 fejlesztői átvágták a gordiuszi csomót: 
ezeket a funkciókat vagy megszüntették, vagy 
annyira átalakították, hogy ne kelljen aszink- 
ron módosításokra hagyatkozniuk. 

( Természetesen amennyiben van Exchange 
2003-as mailboxsszerver az organizációban, il 


letve van olyan alkalmazásunk, amely RUS-t 
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igényel - LoadSim -, akkor nem tudunk 
szabadulni tőle. Ilyenkor az Exchange 2003- 
konzolban lehet RUS-t létrehozni, mene- 
dzselni. Alternatív megoldás: használjuk az 
Update-EmailAddressPolicy, illetve Update- 
AddressList commandleteket.) 

Az Administrative Groups sincs többé. 
Elméletileg az egész organizáció összes szer- 
vere támadható, ha valakinek sürgős admi- 
nisztrátorkodhatnékja van. De csak elméle- 
tileg. Gyakorlatilag az organizáció szintjén 
delegálható jogosultságok léteznek, ezek cso- 
rognak le az egyes szerverekre - így tudjuk 
szeparálni egymástól a különböző szerverek 
adminisztrációs feladatait. 

Mondjuk, ha jobban megpiszkáljuk a 
létezik 


címtárat, láthatjuk, hogy mégis 


Administrative Group. Méghozzá az a ne- 
ve, hogy FYDIBOHE23SPDLI. (Mindez ar- 
ra utal, hogy a fejlesztőnek valószínűleg két 
kutyája van.) 

A név alapján már sejthető, hogy ez az 
Administrative Group szintén a visszafe- 
lé irányuló kompatibilitás miatt jön létre: 


amennyiben van az organizációban Exchange 


[midi x 


Menedzselt folderek. Amikor a levél már 
elért a felhasználó postafiókjába, akkor már 
kikerült a céges házirend által erőltetett sza- 
bályok hatóköréből. Gondolja az egyszerű 
felhasználó. Valójában az Exchange 2007- 
ben érkezik az úgynevezett Managed Folder 
fogalom: be lehet állítani, hogy a felhaszná- 
lók egy csoportjánál mindig jelenjen meg 
egy bizonyos folder - és éljenek az ehhez a 
folderhez rendelt szabályok. Nincs többé me- 
nekvés. 

Keresés. Feljavított Searchfunkcionali- 
tást kapunk. (Search2.0-23.0; ugyanezt hasz- 
nalja az SOLZ2005 159 Ez annyival jobb lett 
az elődjénél, hogy míg az Exchange 2003- 
ban alapértelmezetten ki volt kapcsolva, itt 
pont fordított a helyzet: telepítés után már 


működik is. 


Client Access Server (CAS) szerepkör 
Képzeletbeli levelünk eljutott egy külső fel 
adótól a megfelelő postafiókba. Az egyik le- 
hetséges útvonalon. 

De nem csak ez az egy módszer létezik ar- 
ra, hogy egy kliens - azaz egy felhasználó 


- elérje valahogy a nálunk 





(d Console Root [ETT e: eget 
4.Ú8 Active Directory Domains and Trusts 

154 Active Directory Sites and Services [xch2k7.bel 
4 a Active Directory Users and Computers (xch2k7. 
8.2 ADSI Edít 


(4-4 DNS 
A tj Event Viewer (Local) 
5-£3 Microsoft Exchange 
ala) Organization Configuration 
£a Mailbox 
22 Cent Access 
( kg Hub Transport 
271 Unified Messaging 
5-3 Server Configuration 
Z., Maibox 
A CientAccess 
Za Hub Transport 
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mreri[aci — lévő postafiókot. Az egyik 
lehetséges módszer az inter- 
netes protokollokon keresz- 
tüli elérés. 

A Client Access Server 
szerepkör hasonlít a leg- 


jobban a régi Exchange 





Frontend funkcióhoz: adat 





5. ábra. Házirend az organizációban 


2000/2003-szerver, akkor arról az összes 
Exchange 2007-szerver a fenti izgalmas nevű 
csoportban fog látszódni. 

Adatbázis-határok. A jó hír, hogy az adat 
bázisoknak immár nincs felső mérethatára, 
egyik termékverziónál sem. A rossz hír, hogy 
a felhasználók egész biztosan ezt is megpró- 
bálják majd átlépni. 


Nézzük a konkrét számokat: 


Max Max... Max. database 
Sforage database / Storage 
Group / server / server Group 
Standard 5 5 5 
Enterprise 50 50 J 


Természetesen a fenti számokat a tényleges 


hardver is befolyásolja. 


bázis-kezelés nincs,  min- 

denféle hozzáférés kezelése 
viszont igen. Mit is takar ez a pongyola , min- 
denféle" szó? Gyakorlatilag HTTP, HITPS-, 
POP3., IMA P4-eléréseket. (Az előző kettő tu- 
lajdonképpen az OWA, illetve az ActiveSync 
kapcsolódásokat takarja.) 

Nézzük, hogyan is illeszkedik ez a szerep- 
kör a szervezet architektúrájába. 

Amikor egy külső kliens a fenti protokol 
lok bármelyikén keresztül próbál meg elérni 
egy benti mailbox-szerveren lévő postafió- 
kot, közvetlenül ezt nem fogja tudni megol 
dani - mindenképpen kell az adott Active 
Directory-site-ra egy Client Access Server sze- 
repkört ellátó Exchange-szerver. 

Amennyiben olyan CASsszerveren landol 
tunk, amely másik Active Directory-site-on 
van, mint amelyiken az elérni szándékozott 


postafiók, akkor a CAS-szerver meg sem 
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próbálkozik közvetlenül hozzáférni a távoli 
mailbox-szerverhez - ehelyett megpróbálja 


megkeresni az ott lévő CAS-szervert. Ergo, 


szített "mobileszközök képesek használni. 
Tulajdonképpen arról van szó, hogy e-mail 


cím és jelszó megadása után a CAS leküldi 
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6. ábra. A nem létező Administrative Group neve 





ha egy adott site-on van mailbox:szerver, és 
szeretnénk, ha az azon lévő postafiókok a 
fenti protokollokon keresztül is elérhetők 
lennének, akkor feltétlenül szükségünk lesz a 
site-on egy CAS-szerepkörre is. 

Így áll össze az a bizonyos , szentháromság": 
ha egy adott Active Directory-site-on mail 
boxcszerverünk van, feltétlenül kell mellé egy 
Hub Iransport szerepkör - hogy egyáltalán 
a mailbox-szerver számára legyen SMT Pt-szer- 
ver, azaz levélküldési lehetőség - és erősen 
ajánlott egy CAS-szerepkör is. Ezért nevezik 
ezt a szerepkörhármast , core roles "-nak, vagy- 
is alapszerepköröknek. 

De a CAS-szerepkörnek nem csak ez az 
egy funkciója van. Része emellett az úgyne- 
vezett Availability Service is. Ez az az újdon- 
ság, amely intenzíven veri a szöget a Public 
Folderek koporsójába. 

Arról van szó, hogy a CAS-szervereken fut 
ez a szolgáltatás, és rendszeresen begyűjti/ 
frissíti a mailbox-szervereken található posta- 
fiókokból a felhasználók/erőforrások free/ 
busy, illetve Offline Address Bookinformá- 
cióit, majd ezeket az adatokat egy weboldalon 
keresztül publikálja. Az Active Directory-si- 
te-on tartózkodó modernebb (értsd 2007 jel 
zésű) kliensek (értsd Outlook) már ismerik 
ezt a trükköt, és a Public Folderek helyett itt 
fogják keresni az igényelt információt. 

Ne gondoljuk azt, hogy a CAS-szerver ál 
landóan felolvassa a postafiókok teljes tartal 
mát: a mailbox-szerver lelkesen aládolgozik. 
A szükséges információkat rendszeresen ki 
pakolja egy hálózati megosztásba, XML for- 
mátumban. A CAS innen olvassa fel. 

Egy másik hasznos szolgáltatása a CAS- 
szervernek az Autodiscover Service. Csak 


Outlook 2007-kliensek, illetve erre felké- 


jd 


5-a fetzádninisítalve Groups. 
. 5-£J CN-Exchange Administrative Group (FYDIBOHF23SPDLT) 


a kliensre a komplett MAPL 
profilt, biztosítva ezzel, hogy 
kliensoldalon ne kelljen a fel 
használóknak semmilyen kon- 
figurációs varázslatokkal bíbe- 
lődniük. 

Van még egy érdekes ap- 
róság, amit úgy hívnak, hogy 
LinkAccess: ezzel tudjuk meg- 
oldani, hogy OWA-ból köz- 


vetlenül érhessük el az intra- 





netünkön található, Exchange 
felé publikált fájlokat, illetve Sharepoint 


site-okat. 


Unified Messaging szerepkör 
A másik lehetséges alternatív postafiók-eléré- 
si mód a szövegelés. 

Képzeljük el a következő telefonbeszélge- 


tést: 
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Internal 
phone 





External Fax 


phones 





Exchange 
ActiveSsync 


Internal 
phone 





p RPC/HTTPS 


ep MAPI RPC ———y TDM 


—p HTTPS 
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Unified Ab 
Messaging elet SAN 


ee Directory ös, 


Outlook 
Web Access 


AS 


- Start to read my emails. 
- Stop. [ want to hear this thread details. 
- Stop. [ want to answer to it. 


- [ want to call the email options. Set on 
the read receipt. 

Süt 

- Send it. 

És ez működik! Természetesen nem csak 
az Inboxra - például a Calendar kezelését 
már a kedves olvasó fantáziájára bízzuk. 

A 7. ábrán jól látható, hogy a különböző 
telefonos trükközések után végül is a hang 
IP-csomagok formájában landol a Unified 
Messaging funkciót ellátó Exchange-szerve- 
ren. Ez a szerepkör látja el gyakorlatilag az 
Exchange-Voice illesztést. 

Alapfunkciók: 

Call answering. Üzenetrögzítő (testreszab- 
ható szöveg, rögzíti a beérkező üzenetet, hang- 
fájllevélbe csomagolva landol az Inboxban). 

Fax receiving. Értelemszerű 
(fax az inboxba). 

Subscriber access. Outlook 
(OVA), 


Outlookkezelés telefonon ke- 


Voice Access ezaz 
resztül (hang- vagy nyomó- 
gombiinterfészen). Az IVR me- 
nü itt is testreszabható. 

Auto attendant. lalán ez a 
legérdekesebb. A betelefonálót 
egy menün keresztül betereljük 
az Exchange-organizációba, ke- 
resési lehetőséget biztosítunk 
neki a címtárban, majd amikor 
megtalálta a személyt, akit ke- 


; resett, akkor az Exchange fel 
Outlook 


3] 


hívja nekünk a személy adat 
lapján található telefonszámot. 

Fontos észrevenni, hogy itt 
telefon-Inbox kapcsolat jön 
létre: azaz minden az Inboxba 


kerül, a voice mailek, a faxok 








7. ábra. Unified Messaging és Client Access Server architektúra 


- Hi! II be vour Exchange server today. 


Please type vour email address and password. 


KEREKEKRE 


- Welcome Mr. Bigfoot. 
- Fine. Go to my ÍInbox. 


- OK. 


kényelmesen elférnek a többi, 
hagyományos levél mellett. 
Mit mondhatnánk még itt 
a végén? Mint látható, van újdonság bőven. 
Aki úgy tippel, hogy közülük egynéhányat 
bővebben is kifejtünk a közeljövőben, nem 
jár messze az igazságtól. 
Petrényi József 
(petrenyi.jozsef(osao.hu) SA0-Synergon, MCSE--M, MVP 


Microsoft TechNet 
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CONSOLE 


Az új Exchange-et fejlesztő csapat nagy 


A MEGÚJULT 
ÉEXCHANGE 
MANAGEMENT 


hangsúlyt helyezett az új Management 


Console kidolgozására is — az eredmény 


önmagáért beszél. 


z Exchange Server 2003-ban található Exchange System Manager nem hozott jelen- 
tős változást a megelőző 2000-éhez képest, viszont a 2007-es Exchange-ben már egy 
tényleg felturbózott, vadonatúj koncepció és design köszön ránk. A , régi" felület el 
méletben áttekinthető struktúrán alapult ugyan, mégis sokszor körülményes és időigényes volt 


megtalálni egy megfelelően nagy környezetben a kívánt beállítást - jóllehet csak egy kattintás 


kellene éppen, de az aztán jó mélyen el van rejtve a fastruktúrában. 


Az új konzol tervezésénél 
az egyik fő szempont ennek az 
egyszerűsítése volt, valamint a 
gyakran használt funkciók mi- 
nél gyorsabb elérése. Ebben a 
cikkben áttekintjük az új felü- 
let lehetőségeit, és rögtön né- 
zünk is pár példát az Exchange 


Server 2007 képességeiből. 


A megújult felület 

Mint minden mostanában meg- 
jelent és megjelenő Microsoft 
termék, amelyik MMC-konzolt 


használ, az Exchange Server 


2007 is az ú MMC 3.0-t ve- 
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Console tree 


illet ET áttett 


Ressuult pane 


2  EXCHANGEI2 


2007 
6. Pubkc Default Web Site) Default Web Site . Exchange 2003 or Exchange 2000  Pubbc Folders 


Work pane 





Action pane 








1. ábra. A megújult felület 


szi igénybe, ami a lelke mélyén Windows 
Powershellbscipteket futtat. Ez gyakorlatilag 
azt jelenti, hogy minden grafikus felületen 
végrehajtott módosításnak van egy parancs- 
sori, commandletmegfelelője is. 

Az egyszerűbb navigáció érdekében az or 
ganizáció nem szerverekre van lebontva, ha- 
nem szerepkörökre, erőforrásokra. A meg- 
adott szerepköröket/erőforrásokat kiválaszt 
va látjuk az ehhez tartozó szerverek listáját és 
a rajtuk végezhető műveleteket. 

A konzolt négy fő területre bontották. Bal 
oldalon található a Console tree, amely a 
telepített szerepbkörök szerint csoportosított 
szervereket/erőforrásokat tartalmazza. Itt há- 
rom egységet különböztethetünk meg. Az 
első az Organization Configuration, ahol a 
globális, egész organizációt érintő beállítá- 
sokat módosíthatjuk. A második a Server 
Configuration, ez a szerverszintű adatokat 
tartalmazza szerepbkörök bontásában. A har: 
madik egység a Recipient Configuration, itt 
a címzettek, terjesztési listák és külső kapcso- 
latok tulajdonságait menedzselhetjük. 

Középen felül a Result pane látható, itt a 
Consol tree-ben kiválasztott erőforráshoz/ 
szerepkörhöz, beállításhoz kapcsolódó eleme- 
ket módosíthatjuk. Lejjebb a Work pane 
helyezkedik el. Ez a terület csak akkor je- 
lenik meg, ha a Console tree-ben a Server 
Configuration egy elemével dolgozunk. Jobb 
oldalon láthatjuk az Action pane-t, mely az 
előző 3 panelben kiválasztott objektumok 
függvényében különböző információkat, va- 
lamint az egyes funkciók gyors elérését teszi 
lehetővé. Most nézzük részletesen, hogy a 


Console tree elemei mire is használhatók. 


Organization Configuration 

Itt érhetők el és módosíthatók az egész orga- 
nizációt érintő információk, valamint itt le- 
het elvégezni a jogosultság-delegációt is. Az 
Organization Configuration menüpont alatt 
4 további egységet találunk: 

Mailbox. Itt hozhatunk létre és innen mó- 
dosíthatjuk a címlistákat, offline címtárakat. 
Ezek már korábbról is ismert funkciók, de 
rögtön szembeötlik néhány érdekes újdon- 
ság. A Managed Default Folders fül alatt a 
felhasználók mailboxainak alapkönyvtárait 
találhatjuk, amit tetszés szerint bővíthetünk, 
módosíthatunk. Ennél talán sokkal fonto- 
sabb, hogy alapszabályokat rendelhetünk a 


folderekhez vagy akár az egész mailboxhoz. 


Microsoft TechNet 
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Ezek után a felhasználó átrakhat egy beér 
kező levelet (vagy feladatot, naptárelemet) 
egy ilyen felügyelt mappába, amit a Managed 
Custom Folders alatt hozunk létre, és ekkor 
ezekre az elemekre érvényes lesz az általunk 
beállított szabály. 


63[ xchange Management Console 


(Ele  Acton Yew Help 








ségével megfelelhetünk a különféle, törvény- 
ben lefektetett naplózási előírásoknak, vala- 
mint könnyen szétválaszthatjuk a külső és 
belső levélforgalom naplózását is. Az E-mail 
address policies-ban érhetjük el a régebbről 
megszokott Recipient policies-t. Itt definiál: 
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2. ábra. A Managed Default Folders elemei 


Mire is jó ez? Például arra, ha szeretnénk, 
hogy szerződések vagy a munkamegbeszélések 
anyagai egy rendezett, felügyelhető helyen le- 
gyenek a felhasználók postafiókjaiban, ezeket 
innen akár SharePointba vagy SOL-be is to- 
vábbíthatjuk. Ehhez kapcsolódik a Managed 
Folder Mailbox Policies is, ahol szabályokat 
definiálhatunk, majd azokat különböző fel 
használók postafiókjára érvényesíthetjük. 

Client Access. Ebben az egységben a glo- 
bális ActiveSyncopciókat módosíthatjuk sza- 
bályokon keresztül. 

Hub Iransport. Ebben a szekcióban ál 
líthatjuk be az összes belső kommunikációt, 
levéltovábbítást és kézbesítést érintő opciót. 
A Remote Domain fül alatt egy régen várt 
opciót érhetünk el: itt lehet akár teljes tarto- 
mányonként is szabályozni az üzenetek for- 
mátumát vagy az Out of Office üzenetek kül 
désének lehetőségét. 

Az Accepted Domainben lehet megadni 
az Összes általunk kezelt tartományt, legyen 
az akár az organizáción belül vagy kívül. 

A Transport rule szekcióban olyan szabá- 
lyokat hozhatunk létre, amelyek az üzenetek 
kézbesítését befolyásolják. Gyakorlatilag ez 
is egy nagyon régen áhított opció, például 
ahhoz, hogy másolatot készítsünk az összes 
organizációt elhagyó e-mailről, vagy hogy a 
főnöknek címzett levelekből ki lehessen szűr- 
ni a fizetésemelést érintő leveleket, kivéve, ha 
valaki tudja a varázsszót. 

A Journalingot választva különböző nap- 


lózási szabályokat hozhatunk létre, ezek segít 


DECEMBER-JANUÁR 


hatjuk, milyen e-mailcímeket akarunk auto- 
matikusan generálni a postafiókjainkhoz. A 
varázslón keresztüli beállítás első látásra ta- 
lán kicsit furcsa lehet, de nem nagyon külön- 
bözik az előző verziókban megszokottaktól. 

A Send Connectors az előző verziókban 
megismert SMIP connectors funkcionali 
tásával egyezik meg. A különböző address 


space-ek függvényében külön- 
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Mailbox. Itt érhetjük el az adatbázisokat 
érintő beállításokat. A korábbi verziókhoz 
hasonlóan itt is Storage groupokkal szepa- 
rálhatjuk az adatbázisokat, és ugyanúgy tud- 
juk mountolni, dismountolni őket, mozgatni 
az adatállományokat. Érdemes megjegyezni, 
hogy most már a rendszer által létrehozott 
mailbox storage-en is van méretkorlátozás! 

Client Access. Ebben a szekcióban lehet 
elérni a Microsoft Outlook Web Access, 
Exchange ActiveSync, offline címtár (OAB) 
beállításait. Valójában magát az IIS-t lehet 
itt menedzselni, megfűszerezve az Exchange 
saját opcióival. Az Outlook Web Access fül 
alatt ellenőrizhetjük az OWA alapkönyvtárai 
nak tulajdonságait, többek között itt lehet be- 
kapcsolni a Form Based Authenticationt is. 

Hub Transport. Míg az előző részben 
NP őrotokollecállíthattukébe Stt saz 
SMIP protokoll tulajdonságain módosítha- 
tunk. Alapbeállításként két connectort ta- 
lálunk, ezek: a Client (szervernév), valamint 
a Default (szervernév). Nyilván a Default 
connector a 25-ös porton fogadja a beérkező 
üzeneteket a nagyvilágból (fontos: ez nem 
azt jelenti, hogy az internetről - csakis szi- 
gorúan megbízható helyekről), míg a Client 


az 587-es porton várja a kliensüzeneteket. 








böző szerverekhez továbbíthat 
jük akár DNS vagy smarthost Eza 
segítségével az üzeneteinket. He 
Az Edge Subscription segítsé- EJ Exceptions 
gével pedig az Edge Iransport leeátn 
szerepkörű szerveren telepí 
tett ADAM és a saját Active 
Directorynk közötti konfigu- 
Taciós adatok szinktonizaciójaát 
tudjuk biztosítani. 

Az Exchange Server 2007- 
ben bemutatkozó újdonság a 
Unified Messaging (UM), ami 
hang/fax/e-mail alapú üzene- permi 





Tr a New Transport Rule 


Exceptions 

Step 1: Select exception(s) if necessary: 
[d except when any of the recipients in the To field or Cc field is people Él 
(d except when any of the recipients in the To field or Cc field is a member of díistributic 
(d except when the text specific words appears in the subject 
M except when the text specific words appears in the subject or the body of the messz 
(D except when the text specific words appears in a message header 
(d except when the From address contains specific words 
[d except when the text text patterns appears in the subject 
([T except when the text text pattermns appears in the subject or the body of the messag 
[d except when the text text patterms appears in a message header 
(Ü except when the From address contains text patterns 
[d except when the text text patterns appears in any attachment file name 

TI extent with a snam confidence level (SCI 1 that ix oreater than or enual ta krnit e 





! Step 2: Edit the rule description (chick an underlying value): 





Apply rule to messages 
when the Subject field contains fizetésemelés 





silently drop the message 


except when the text varázsszó appears in the subject or the body of the 
message 





dei ] eni ] 








tek közös store-ban tárolását te- 
szi lehetővé. Az ugyanilyen ne- 
vű pont alatt állíthatjuk be az egész organi- 
zációt érintő szabályokat, tulajdonságokat. 
Gyakorlatilag itt egy leképezést végzünk a te- 


lefonrendszerünkről az Active Directoryba. 


Server Configuration 
A Server Configuration rész alatt találjuk 
organizációnk szervereit szerepkör szerinti 


bontásban: 


3. ábra. Szabályok végtelen variációja Transport Rule definiálásakor 


Természetesen lehet állítani a használandó 
IP-ket, portot, hogy milyen IP-kről érhető el a 
connector, és állíthatjuk az autentikáció típu- 
sát is (Basic, Intergrated, ILS stb.). 

Edge Transport. Ezzel a ponttal csak ak- 
kor találkozunk, ha az organizációnkon belül 
van Edge Iransport szerepkörű szerver. Ezek 
a szerverek felelősek az internet irányába kül 


dött és onnan érkezett levelek tisztaságáért. 


Le 
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A Hub Iransporthoz hasonlóan itt is egy 
SMI Psszerverről beszélünk, valamint az eh- 
hez kapcsolódó AntiSpam és AÁntivirus szol 


gáltatásokról. Itt is megtalálható a Receive 


ki kell választani, hogy meglévő felhaszná- 
lóhoz akarunk-e postafiókot rendelni, vagy 
új felhasználót hozunk létre. Ezek után még 
néhány általános tulajdonság következik, és 


már kész is a postafiók. A pos- 








) . 
ab New Mailbox 
[d Introduction Introduction 
(7 User Type This wizard will guide you through the steps for creating a new mailbox, resource mailbox, 
linked mailbox and mail-enabing an existing user. 
L1 New Mailbox e 
za f C User Mailbox 
This mailbox is owned by a user to send and receive messages. This mailbox cannot 
be used for resource 
6 ifigom Maibox ! 
The room mailbox is for room scheduling and is not owned by a user. The user 
account associated with resource mailbox will be disabled. 
C Eguipment Mailbox 
The eguipment mailbox is for eguipment scheduling and is not owned by a user. The 
user account associated with resource mailbox will be disabled. 
 C LinkedMaibox 
Linked mailbox is the name for a mailbox that is accessed by a security principal (user) 
in a separate, trusted forest. 
Help l c Back l Next, Cancel l 


tafiók tulajdonságait megnézve 
láthatjuk, hogy azok nagyban 
hasonlítanak az előző verziók 
ADUC füleire és opcióira. 
Distribution Group. Itt me- 
nedzselhetjük terjesztési listáin- 
kat és a hozzájuk kapcsolódó 
beállításokat. Új lehetőség a di 
namikus terjesztési lista létreho- 
zása, amelyben a csoporttagsá- 
got különböző felhasználói tulaj- 
donságok alapján adhatjuk meg, 


nem kell egyesével belerakni 





csoportokba a felhasználókat. 





4. ábra. Mailbox-típusok 


Connector, a Send Connector, a Iransport 
Rules és az Accepted Domains. Ami ismeret 
len lehet ebben a környezetben, az az Anti 
Spam fül. Többek között az alábbi techniká- 
kat és technológiákat aktiválhatjuk itt (amik 
mind transport agentek amúgy, és akár Hub 
Iransport szerepkörű szerverre is feltehetők): 
Content filtering, IP Allow list, IP Allow List 
providers, IP Block list, IP Block List pro- 
viders, Recipient filtering, Sender filtering, 
Sender ID, Sender reputation. 

Unified Messaging. Ezen keresztül konfr 
gurálhatjuk a hangüzenet, fax és e-mailküze- 
neteket egy store-ba, amelyet a felhasználók 
elérhetnek számítógépen, de akár telefonon 


keresztül is. 


Recipient Configuration 

A korábbi verziókban a címzettek beállításait 
(postafiókok, címlisták, külső kapcsolatok) az 
Active Diretory Users and Computers MMC 
segítségével lehetett elvégezni. A 2007-ben 
ezt is bevonták az Exchange Management 
Console-ba. 

Mailbox. Valószínüleg az egyik legtöbbször 
használt rész lesz, ugyanis itt hozhatunk létre 
postafiókokat, és itt is távolíthatjuk el őket 
a rendszerből. Létrehozásnál meg kell hatá- 
rozni, milyen típusú postafiókot akarunk 
létrehozni: felhasználói postafiókot, erőfor- 
rás- (szoba- vagy eszköz) postafiókot, illetve 
organizáción kívüli trusted domainben levő 


felhasználó postafiókját. A második lépésben 
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Mail Contact. Felületet biz- 
tosít az organizáción kívüli sze- 

mélyek levelezési opcióinak beállításához. 
Disconnected Mailbox. Itt láthatjuk az 
olyan mailboxok listáját a store-ban, ame- 
lyekhez nem tartozik felhasználó/erőforrás 


az Active Directoryban. 


Toolbox 

Szerszámosládánkban Kés végre valóban szer- 
számosládaikonja van) jóval több hasznos 
eszközt találhatunk azt elődökhöz képest. 


Négy eszközcsoportot külön- 


gozásával kapcsolatos eszközök állnak ren- 
delkezésünkre. Három elemet találunk itt: 
Mail Flow Iroubleshooter, Message Iracking 
tool, Oueue Viewer. Érdekes újdonság, hogy 
mind a Message Iracking Tool, mind a Mail 
Flow Iroubleshooter az előzőekben említett 
Exchange Iroubleshooting Assistant eszközt 
használja. A Mail Flow Iroubleshooter segít 
ségével különböző tüneteket megadva pró- 
bálja meg a rendszer helyettünk megtalálni a 
probléma forrását. 

Az utolsó csoportba kerültek a teljesítmény- 
méréssel és diagnosztikával foglalkozó esz- 
közök. A Performance Monitor segítségével 
Exchange teljesítménymérő értékeket ellen- 
őrizhetünk (RPC-kérések száma, helyi kézbe- 
sítési arány). A Performance Iroubleshooter 
szintén az Exchange Iroubleshootert hívja 
segítségül a teljesítményt érintő problémák 


megoldására. 


Összegzés 

Az új Exchange Management Console sok új- 
donságot hoz, mint ahogy maga az Exchange 
Server 2007 is. Ebbe a végeláthatatlan lis- 
tába tartozik például a szerver föltelepítését 
követően az első indításkor látható Exchange 
Server Finalize Deployment varázsló is, 
amely segítséget nyújt abban, hogy milyen 
lépéseket is kell megtennünk egy jól műkö- 


dő és biztonságos levelezőszerver üzemelteté- 








EJ Exchange Management Console 


Ele Action  Wew Help 








böztethetünk meg: első a Con- 






figuration Management 1ools, 
amelyben jelenleg egyetlen esz- 
köz árválkodik, viszont ez az 
egyik leghasznosabb. Nevezete- 
sen ez az Exchange Server Best 
Practices Analyzer. 

A második csoport a Disaster 
Recovery Tools két hasznos esz- 
közzel, nevezetesen a Database 
Recovery Management toollal 
és Database Iroubleshooterrel. 
Mindkettő azonos külső prog- 


ramot használ, mégpedig a szin- 


e 21mimieim 





8 objects HLsúLi 


5  Toolbox 
Configuration management tools 





7 Best Practices Analyzer View ; 
" — Check the configuration and health of your Exchange topology 
B Refresh 
Disaster recovery tools 2 Help 
d mesz EK y la 
Manage disaster recovery scenario £ú Opentodi 
27 ő) Database Troubleshooter (2 Help 
9094 Troubleshoot store mounting and other database-telated problerr 
Mail flow tools 
—f1- Mail Flow Troubleshooter 
zer Troubleshoot mad flow and ttansport-elated problen 
—ő1- Message Tracking 
LDT Examine message ttiacking log 
A Oueue Viewer 
/ Manage Exchange mad gueue 


Performance tools 


meret erszeeyer 
9 Troubleshoot Exchange performance probler 








tén az előbbi linken találha- 
tó Exchange Iroubleshooting 
Assistantot. Mindkét eszköz hasznos lehet 
adatbázishibák felderítéséhez és kijavításá- 
hoz, storage groupok és postafiókok vissza- 
AA SÁlNOZ 

A harmadik csoportban (Mail Flow Tools) 


a levelek küldésével, fogadásával és feldol 


5. ábra. Szerszámosláda 


se érdekében. [de tartozik szintén a rengeteg 

új varázsló, amelyek részletesen, ugyanakkor 

áttekinthetően segítenek bennünket felada- 
taink elvégzésében. 

Subicz Péter 

Exchange Server MVP (splistas(ostn.hu) 


Microsoft TechNet 
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K : 

Keresés. Gyors és egységes keresőmotort 
kapunk, ami végre ugyanazt az algoritmust 
használja mind kapcsolódott, mind kapcso- 
lat nélküli üzemmódban, akár van lokális 


cache-elésünk, akár nincs. Ha viszont ép- 


pen van aktív kapcsolatunk az Exchange 
Serverhez, akkor a keresést a szerver is el tud- 

[BEI R HE ja végezni a kliens helyett. 
Managed folders. Ezek olyan, rendszer- 


gazda által létrehozott könyvtárak, amelyek 


SharePointintegráció. Mind az Outlook 
2007, mind az új OWA képes az intraneten 
található SharePointwebhelyek, -listák, -állo- 


mányok szinkronizálására és publikálására, 





így közvetlenül az Outlookból érhetjük el a 


számunkra legfontosabb adatokat. 





ő p minden megadott felhasználónál megjelen- 
Ke e sSzamuUn kat Ura ló Exch an J e 9 erver nek, és ha beletesz a felhasználó egy Outlook- 
elemet (levelet, feladatot - bármit), azon le- 
20 0/ mel lett a Microsoft Office- ba n futnak azok a szabályok, amiket beállítunk. 
7 jő B F v Ilyen módon nagyon kényelmesen lehet az 
Ta 3 a 3 n ató oO utI ele ke ki lenS 2 Ö 0/- eS Va Htozata IS ! egész cégre kiterjedő dokumentumkezelési 
E8 8 szabályokat megvalósítani (például szerződé- 
SZO 3 J ál kel le mes meg le elése kkel 8 sek és üzleti levelezések egységes kezelése, 
archiválása, előírásoknak megfelelő automa- 

tikus kezelése). 

Spam. A levélszemét kezelése is sokat vál 
ássuk, mik a legérdekesebb újdonságok! tozott mind a kliens, mind a szerver olda- 
Automatikus konfiguráció. Az Exchange Autodiscover Web Service segítségével a már ! lán, azonban ezzel részletesen foglalkozunk a 
eleve domainbe léptetett Outlook 2007-kliensek bármiféle felhasználói interakció nébt ! Magazin egy másik cikkében. 

kül is képesek kapcsolódni a rendszergazda által kijelölt Exchange Serverhez, illetve a már Összességében elmondható, hogy az Out 
létrehozott mailboxhoz. Egyszerűen, már az Outlook 2007 első indításakor, egy gomb meg- ! look-kliens továbbra is az egyik legkényel 


nyomása után levelezhetnek felhasználóink, anélkül, hogy szerverneveket, e-mail-címeket, jel: ! mesebb felület a mindennapos irodai mun- 






szavakat, portokat kellene beírniuk. 





Z Microsoft Technet - Microsoft Öutlok 


Naptárkezelés. A naptárkezelés üzleti logikája teljesen átkerült az Exchange Server HÖBZBKEÉSE LSE KB 
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] 2 Monday 
a (u Petrényi Józset HATSZ 


H.2006.12.18. 1710 


499 09-oL Tal 













UI 59994 "00-01 Li 


" a) Szabó Gábor H1740 
3 fA Portaljáa - Peter Budai Ünti agency Exchange 2097 Amti-spon 
(9 Deleted Rem: 







Feladatok kezelése. A feladatok nagyobb szerepet kaptak, mint korábban. Nemcsak 









munka elvégzésére (evélszemét szűrés, vinasvédelem) ódeális hely. Ezen logika mel 
a) taláhunk ant-apam transport ügynököket a Management Console-ban ! 
."  Mivanha nem akarunk (vagy nem todunk) dedikált Edge szervert kialakítani? / 





2) Last Week 


A Petrényi Józset 












! 
Az Edge szerveten kívül már csak a Hub szervet rendelkezik SMTP motowal, így j/ 
a gpam-et (mivel Huba már jól megfér együt a többe szereplővel és így nem kel e/ 


[A Dratts is 
CA tobaw ups 


(Ad inbor 


Vv19o9 


külön listaként láthatjuk, hanem naptárunkhoz is rendelhetjük őket: így láthatjuk, 






















I Tamás 20 1214 ! 
Gál Tt. $20 1216. 
B hír! Lehöségünk van arra, hogy 2 Hub szerveren is "bekapcsoljuk" az anti-spani 





mikor kellene elvégeznünk az adott feladatot, valamint hogy végül mikor sikerült. A 








ao Tens 5201216. Ehhez a következőket kell tenműnk- j j 


1. Indétsuk el az Exchange Management Shell-t 
2 Lépjünk be az " Exchange Server Scripts" könyvtárba 
3 Gépekük be a" amagents parancsot j 








2 Petrényi Józset P1215 


feladatokhoz hasonló módon kezelhetünk bármilyen más Outlook-elemet is, így akár 





8) fétiMarcen P121s$ 


swse4 15 :4mpos -€ 










e Folders 2 
4 Aj sechivt Fodőers 3 


leveleket, RSS-bejegyzéseket is megjelölhetünk feladatként, és ezeket akár a naptá- 


Ed Petrényi Józset P1215 


d féti Marcen €51214. 








runkba is ránthatjuk: megjelölendő, hogy mikor is szeretnénk foglalkozni vele. 







d GálTamás Cs1214. 


d GsiTamás Cs1214 


RSS-támogatás. Az Outlook 2007 ugyanúgy kezeli az RSS-csatornákat, mint a ha- 






ad Gáltamás K1212 








d GálTamás K1212 


gyományos levelezést. A klienst használva archiválhatjuk, kereshetjük, rendezhetjük 





Ezt követően megjelenik az anti-spam fül az Exchange Management Consc 
Transport menü alatt (ha az instalkkcsó alatt a Management Console nyitva 
ágyán Várvani 


és kényelmesen olvasgathatjuk a számunkra érdekes bejegyzéseket, vagyis pontosan 














Allfölders are upto date. £3 Connected to Microsoft Exchange " 


ugyanúgy használhatjuk az RSS-bejegyzéseket, mint a hagyományos leveleket. 
Hangüzenetek kezelése. Nemcsak elektronikus dokumentumokat és írásokat, Beépített RSS-kezelés az új Outlookban 

hanem hangüzeneteket is tárol az Outlook 2007 - már amennyiben használjuk az 

Exchange Unified Messaging szerepkörét. A nekünk hagyott hangüzenetünket meghallgathat ! kához, és folyamatosan egyre több képesség 

juk közvetlenül az Outlookból, ahol pontosan látszik az üzenet időpontja, feladója is. épül bele a hatékonyabb csoportmunka tá- 
Új Outlook Web Access. Ismét sokkal több funkció érhető el az Outlook webes felületéről, ! mogatására is. 

így most már egy szinte minden tekintetben teljes értékű klienst használhatunk hagyományos Budai Péter 

internetkapcsolat megléte esetén is, távol a belső hálózattól. (i-pbudai(oOmicrosoft.com) Microsoft Magyarország 
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Az Exchange Server 2007 üzemeltetéssel kapcsolatos újdonságai 


közül talán a PowerShell-parancsgyűjtemény a legnagyobb áttörés 


az Exchange 2003-hoz képest. 


z Exchange Server üzemeltethetőségének tervezésekor a cél a felhasználói felülettel 
rendelkező üzemeltetési eszközökkel egyenértékű támogatott és dokumentált script 
parancsok fejlesztése volt. Ez össze is jött, és nem is akárhogyan! 

Az Exchange Management Shell néhány parancsának gyakorlati bemutatásával az a célunk, 
hogy az olvasónak - ha még korábban nem jött volna meg - meghozzuk a kedvét a használa- 
tához. A következő oldalakon a kétkedők is megbizonyosodhatnak arról, hogy milyen egysze- 
rűen, milyen hatékony és összetett dolgokat lehet művelni a PowerShell használatával. 

Már az Exchange Server 2007 architekturális áttekintésekor is számtalanszor hivatkoztunk ar- 
ra, hogy egyes feladatok elvégzése az Exchange Management Console segítségével nem, vagy csak 
limitáltan lehetséges. Emiatt a Windows PowerShell alapú, Exchange Management Shellben ki- 
adott scriptek, utasítások nemcsak a meglévő képességek automatizálására kiválóak, hanem arra 
is, hogy a felületre ki nem vezetett funkciókat azok teljességében használatba vehessük. 

Az Exchange Server 2007-tel közvetlen kapcsolatban álló parancsok listáját az Exchange 
Management Shell elindítása után a getexcommand parancs kiadásával érhetjük el. A paran- 
csokról a Windows PowerShellben megszokott eszközökkel kaphatunk részletesebb segítséget, 
példákat is. 


Kellene még pár mappa, amivel tesztelhe- 


tünk! 


New-PublicFolder—Name "Teszt Nyilvános Mappa" 
—Path "V 


Csináljunk most már valami izgalmasab- 
bat is: módosítsuk az új mappánk kliensszin- 
tű (MAPD jogosultságait. Az aktuális jogo- 
sultságok: 


Get-PublicFolderClientPermission —Identity "Veszt 
Nyilvános MappavAlmappa" 


Szeretnénk egy új felhasználót hozzáadni 


az ACL (Access Control List)-hez, viszont 





ez Etats ús a ] Scope: futureinc.com 


Jet mt sé Lesi tipirl SettingsYAdministrator2get-— PublicFolderClientPermission ET. 
HANETEG Teszt Nyilvános MappaMÁlmappa" 


Nyilvános mappák kezelése, jogosultságállítás 
A kínálat bemutatását a nyilvános mappákkal kezdjük. A telepítés 


Identity 


Md EE r Nyilvános Mappax. . . 
MU E-ETi r Nyilvános Mappax . . . 
XTeszt Nyilvános Mappaxs... 


után a Mailboxsszerverünkre nem települt Public Folder adatbázis 
(mivel nem pipáltuk be a telepítőben, hogy van Outlook 2007-nél 
régebbi kliensünk is - lásd a telepítéssel foglalkozó cikket), így a 
Windows PowerShell erejét kihasználva hoztunk létre egyet: 


New-PublicFolderDatabase —Name "Public Folders" —StorageGroup "First Storage Group" 


Hosszú, izgatott várakozással töltött másodpercek, és már el is készült! A következő parancs- 


csal le is kérdezhetjük a tartalmát: 
Get-PublicFolder 


A GetPublicFolder -Recurse bejárja a teljes mappastruktúrát, míg a -Recurse paraméter 


nélkül csak a legfelsőbb szintű mappákat kapjuk vissza. 


16 


Default 
futureinc.com/Users/fdnm. .. 
elni át uTt tt ési 





rlodod-érésd pa kr dj rési 


€futhor? 
£Owner? 
€Createltems2 





a környezet annyira új, hogy még csak az 
Exchange Admin felhasználó létezik. Újra 
kihasználjuk a PowerShell erejét, és csiná- 


lunk egy új Exchange-mailboxot: 


New-MailUser—Name "Teszt user" —ExternalEmailAddress 
tesztuserofutureinc.com . —UserPrincipalName . teszt- 
vserrOfutureinc.com —OrganizationalUnit futureinc.com 


Ezután szabad a pálya az ACL módosítá- 


sához. 


Microsoft TechNet 
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Ha ezeknél komplexebb műveleteket szeret 


nénk végezni, a CNProgram FilesxMicrosoftN 


Exchange ServerScripts mappában egy szép 


lalkozunk. Csapjunk rögtön a közepébe! Az 
alábbi példák azt mutatják, hogy egy ki 
csit összetettebb, de még mindig egyetlen 


sorból álló scripttel milyen nagysze- 





User AccessRights 


(Createltems2 


XATeszt Nyilvános MappaX... futureinc.com/Teszt user 


dentity "Teszt Nyilvános MappaMAlmappa" 


AccessRights 


Default 
futureinc.com/Teszt user 


£futhor? 
(Createltems?2 
futureinc.com/Users/Adm... £Owner? 
Ánonymous (Createltems? 


XTeszt Nyilvános Mappax... 
XTeszt Nyilvános Mappaxs... 
XTeszt Nyilvános Mappax... 
XTeszt Nyilvános Mappax... 





scriptgyűjtemény áll rendelkezésünkre, többek 
között az AddUserslIoPFRecursive.ps1 script, 
amelynek használatával egy egész nyilvános 
mappa fa-csomópontjainak ACLijeit gazdagít 
hatjuk a felhasználónkkal. Lépjünk be a map- 
pába, és futtassuk a (PowerShell) scriptet: 


AddUsersToPFRecursive.ps] —TopPublicFolder ""Neszt 
Nyilvános Mappa" —User "Teszt user" —Permission 
Createltems 


A -TopPublicFolder paraméter után a 
mappa nevét három idézőjel közé raktuk, 
hogy a script megkapjon egy idézőjelet (dupla 
idézőjel idézőjelben). Külön érdekesség, hogy 
ha nem adunk meg "dupla" idézőjelet, akkor 
a script nem működik olyan "root" mappák- 
kal, amelyeknek szóköz van a nevében. 

A fenti commandleteken kívül még szá- 
mos parancs rendelkezésünkre áll nyilvános 
mappák kezeléséhez: például replikáció, a 
"mailtenable" állítása. Végezetül nézzünk egy 


példát ez utóbbira: 


Enable-MailPublicFolder  —Identity ."Weszt Nyilvános 
Mappav4lmappa" 


Az összes mailenabled nyilvános mappát 
(a mi esetünkben csak egy van) pedig a követ 


kező paranccsal tudjuk lekérdezni: 
Get-MailPublicFolder ] Format-List 


A kimenetet átirányítottuk a FormatlList 
parancsnak, amely megformázza a kimene- 
tet. Ha az eredményhalmaz 1000 elemnél 
többet tartalmaz, akkor csak az első 1000 ele- 


met adja vissza. 


$$$ e/7 


E-mail-felhasználók és disztribúciós 
listák kezelése 


A következőkben az e-mailfelhasználók és 


disztribúciós listák körüli műveletekkel fog- 


DECEMBER-JANUÁR 


FB Machine: fdc ] Scope: futureinc.com aj 


5] CC: Documents and SettingsYÁdministrator?add-PublicFolderClientPermission sel a] 
dentity "NTeszt Nyilvános MappaMAálmappa" -user "Teszt user" —accessrights Create 


c: Documents and SettingsXAÁdministrator?2get-PublicFolderClientPermission -I 





sz DII 
rű dolgokat végezhetünk el. A fel 


adat egyszerű: importáljunk be egy 
.CSV fájlban tárolt felhasználókat 
az Active Directoryba, és csináljunk 
nekik mailboxokat. A .CSV fájl el 
ső sorában definiáltuk az oszlopok 
neveit (Alias, Name), utána pedig a 
felhasználók aliasait, hosszú neves formában 
felsorolva. 

A script első felében beolvassuk a beme- 


netről (a billentyűzetről) a feladat elvégzésé- 


is NNP 


Egy másik, a mailboxjogosultság beállítá- 
sára szolgáló parancs az add-AdPermission, 
amely az Active Directory-beli user-objektum 
ACLJjJét módosítja. A következő példában 
ezzel a paranccsal , Send-as" jogot adunk az 


egyik tesztuserünknek: 


Add-AdPermission administrator —ExtendedRights Send- 
As —User kjeno 


A ,send on behalf" és ,send as" jogo- 
sultságok két különböző , megszemélyesítést" 
(vagy helyettesítést) jelentenek: míg az előb- 
binél a címzett látja a levél valódi küldőjé- 


nek e-mailkcímét, addig az utóbbinál 





[ez Eta ata ee ti feet riált atást 11) 


IPS1 C:sxogpassword - Read-Host "Password" -AsSecureString; import—csyu userps.csu [al 
: foreach (new-Mailbox -—alias "5c$ .Aliasd" -Name "§(§ .Name)" -Org futureinc.co 


úgy tűnik számára, mintha valóban 


m/Users -UserPrincipalName $§ .Álias?BPfutureinc.com" -Database "Mailbox Databa 


se" -Password S$password? 
PassSwopd: 3E9EREREREZEIEIEIE9E3€9€3€9E 


Name iz ServerName 


unlimited 
unlimited 
unlimited 





hez szükséges jelszót, és nem adjuk azt meg 
szövegként a script részeként. 

Ezután csináljunk egy disztribúciós listát, és 
tegyük bele a felhasználóinkat. Disztribúciós 
listát a felhasználókhoz hasonlóan, egyszerű- 


en a következő paranccsal készíthetünk: 


New-DistributionGroup —Alias ujUserek —Name "Új 
userek" —Iype Distribution —Org futureinc.com/Users 
—SamAccountName usUserek 


Csoporttagságokat pedig az előbb már 
megismert importcsv commandlet haszná- 
latával, variálva az add-DistributionGroup- 


Member paranccsal vihetünk fel: 


Import-csv users.csv. ] foreach ((Add-DistributionGroup- 
Member —Identity ujUserek —Member "$($... .Alias) "9 


Mailbox-jogok beállítása 

A következő parancsok a mailboxok jogosult 
ságainak beállítására szolgálnak. Az első a set 
Mailbox, amellyel a mailbox különböző tu- 


lajdonságai módosíthatók, pél 


jét kör ktrti-i et LV [TT] 
Lél 


a helyettesített személy írta volna a 
levelet. 

Végül a mailbox ACL/jJét kibővít 
hetjük egy full mailbox access jogo- 


sultsággal: 


Add-MailboxPermission administrator —AccessRights 
FullAccess —User trapi 


Összefoglalás 

Fontos még egyszer megjegyezni, hogy az 
Exchange körüli valamennyi karbantartási és 
üzemeltetési feladat megoldható PowerShellL 
parancsokkal, és olyan dolgokat is elvégezhe- 
tünk vele, amelyeket más (grafikus) eszközök 
kel nem tudnánk. 

Korábban a hasonlóan komplex feladatok 
elvégzésére egyedül a fejlesztők voltak képe- 
sek a számukra kialakított APLk és osztály- 
könyvtárak segítségével - azonban most már 
ezt bármelyik rendszergazda megteheti né- 
hány egyszerű script írásával. 

Remélhetőleg sikerült felkelteni az olvasó 
érdeklődését a PowerShell alkalmazása iránt 
- akinek viszont még nem jött volna meg a 


kedve, annak akkor fog, amikor először auto- 





EZ Machine: fdc ] Scope: futureinc.com 


dául különböző userkvóták, a 
maximálisan fogadható e-mail 
méret, a felhasználó teljes neve 
stb. Ugyanezzel a paranccsal ki- 


osztható a , send on behalf" jogosultság is: 


set-Mailbox administrator -GrantSendOnBehalfTo kjeno 


futureinc.com/lse.. 


o ] C:X2add-MailboxPermission administrator -AccessRights Fullfccess -user trapff 


User AccessRights IsInherited Deny 


A STT A aA ALL eő ZH B A Kö ZTH LL [st ESÉS 





matizálni szeretné valamely Exchange körüli 
feladatát. 

Szabó Dávid 

(dszabocomicrosoft.com) Microsoft Magyarország 
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TERVEZÉS ÉS 
TELEPÍTÉS 


Alapos tervezésnek kell megelőznie 








a tényleges telepítést — ezzel később rengeteg 
időt és energiát spórolunk meg magunknak. 


tt van a kezünkben az Exchange Server 2007 telepítő-cédéje, nosza dugjuk be a gépbe, és 
telepítsünk! Amennyiben így jártunk volna el, garmadával követtük volna el a hibákat. 
Vagyis tegyük szépen vissza a cédét a fiókba, emeljük le a polcról az internetet... vagy ezt az 


újságot (legjobb, ha mindkettőt), és gondoljuk végig, mit is szeretnénk, hogyan is szeretnénk. 


Szerepek 
Az új Exchange-verzióban az elemi funkciókat szétválogatták, és csoportokba rendezték. 
Ezeket a csoportokat nevezzük szerepköröknek. 

Ha visszagondolunk az elődre (Exchange Server 2003), abban tulajdonképpen sok szerepkör 
nem volt, csak a background és frontend szerver. A background szerveren futott egy adatbá- 
zis-motor (ESE, leánykori nevén JET), ez kezelte a levelezési adatokat: a leveleket, a naptárbe- 
jegyzéseket, kontaktokat, taszkokat, amelyek tartozhattak felhasználókhoz, illetve nyilvános 
mappákhoz. A felhasználók elérhették az adatokat MAPI felületen (a jó öreg RPO), illetve in- 
ternetes protokollokon (POP3, IMAP4, HTTP) keresztül. A frontend szerver ettől annyiban 
különbözött, hogy lemondott az adatbázis kezeléséről, cserébe egyfajta előtét szerepet vállalt 
fel az internet felőli elérésekhez: kezelte azokat a weblapokat, amelyeken keresztül a HTIP/ 
HITPS-kliensek (OWA, OMA, ActiveSync) bedöngettek a szervezetbe. Mindemellett célszerű 
volt vagy erre a szerverre, vagy egy külön beiktatott smarthostra telepíteni valamilyen levelezé- 
si higiéniát biztosító funkciót is (itt a vírus és spam elleni védelemre kell gondolni). 

Lássuk, tervezési és telepítési szempontból mit kell figyelembe vennünk a szerepkörökkel 
kapcsolatban. 

Edge Transport szerepkör. Kezdjük rögtön a különccel: 
an Nem kötelező a szerepkör megléte. Tulajdonképpen nagyon jól elvan nélküle az organizáció, 

a feladatát - persze jócskán leegyszerűsítve - el tudja látni a Hub Iransport szerver is. 
an Nem kötelezően tartományi tag. Ez merőben új dolog, mert eddig először be kellett léptetni 

a gépet a címtárba, hogy utána felugorhasson rá egy Exchange-szerveralkalmazás, amely már 

tagja lehetett az organizációnak. 

Ha röviden akarnánk jellemezni ezt a funkciót, akkor azt mondhatnánk, hogy ez az 
Exchange-szerver látja el mindazokat a funkciókat, amelyekre eddig jellemzően nem Exchange- 
szervereket szoktak használni. Ez a smarthost, amelyik a levelezési higiéniáért felelős. 

Hub Iransport szerepkör. Mindent tud az organizációról. Tudja, hogy mikor hová kell 
mennie egy levélnek. Nála van a Nagy Szabálykönyv, amely kegyetlenül meghatározza, mi tör- 
ténjen a mezei levelekkel. 


Client Access Server (CAS) szerepkör. Mint a neve is mutatja, ez kezeli a kliensoldali hozzá- 


R. 
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féréseket. Ez a munka áll legközelebb a régi 
frontend szerepkörhöz: rajta keresztül megy 
az OWA, az ActiveSync - és ide került a 
POP3;, illetve a IMAP4-hozzáférések kezelé- 
se is, illetve ezen keresztül érhetik el az egye- 
di webes fejlesztések az organizációt. Azaz 
minden itt tobzódik, ami nem MAPI. (Ha 
valaki esetleg hiányolná az OMA-tt, nem kell 
végleg elsiratnia: funkcionalitása beleolvadt 
az ActiveSync-be.) 

Unified Messaging szerepkör. Ez a funk- 
ció abszolút új. Célja a telefonközpontok 
és az Exchange-kapcsolódás megvalósítása 
mind hang:-, mind faxvonalon. 

Mailbox Server szerepkör. A legkonzer 
vatívabb funkció a családban. Gyakorlatilag 
fogadja a MAPlLn keresztül érkező igényeket, 
kezeli az adatbázisokat - ez maga a tulajdon- 


képpeni klasszikus levelezőszerver. 


A szerepek lehetséges megosztásai 
Hogyan érdemes elosztani az egyes funkció- 
kat a rendelkezésre álló szerverek között? 
Rögtön az I. ábránál szembesülünk azzal, 
hogy még nem is beszéltünk minden szerep- 
körről sÖOtt van úgyanis aeGlobalelcatalosg 
Server funkció. Bár ez szigorúan véve nem 
az Exchange része, de azért tudjuk, hogy 
Active Directory nélkül nincs Exchange sem. 
Márpedig a címtárat - legalábbis a címtár 
tartományi partícióit - a globális katalógu- 


son keresztül használja az Exchange. 
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1. ábra. A legegyszerűbb szerepkörkiosztás 


Nyilván nem mondunk nagy újdonságot 
azzal, hogy Global Catalog szerver önállóan 
nem létezik, a funkciót csak tartományvezér- 


lőre lehet telepíteni. 


Mire is jó a Global Catalog? 
Egy kis kitérőt érdemes itt tennünk, ugyan- 


15 a tapasztalatok szerint a Global" Cátalóg 
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funkció megértése általában problémát szo- 
kott okozni. 

Az Active Directory partíciókból áll, ezek: 
séma-, konfiguráció- és tartományi partíció. 
Sémából és konfigurációból is csak egy lé- 
tezik erdőszinten, míg tartományi partíció- 
ból annyi van, ahány tartomány az erdőben. 
Miket tartalmaz ezekből az adatokból egy tar 
tományvezérlő? Attól függ. Mindegyik DC-n 


ott van az erdő teljes konfigurációs partíciója, 


kát annak nyakálba vartunk: ez ar tartomany: 
vezérlő, a globális katalógus, az Exchange- 
szerver, sőt, délutánonként ez takarítja ki 
a szerverszobát... Értelemszerűen az összes 
Exchange 2007-szerepkört is ez látja el. 

Mi is ez az összes? Figyelmesebb szemlélő- 
nek például feltűnhet, hogy nem látja az áb- 
rán az Edge Iransport szerepkört. Nem is. 
Egyfelől ez nem kötelező, másfelől pedig nem 
telepíthető semelyik másik funkció mellé. 


(Emlékezzünk rá, hogy ez a funk- 
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írható változatban. Ugyanúgy ott van a teljes 
sémapartíció, de ez csak a Schema Master sze- 
repet ellátó gépen írható. És minden tarto- 
mányvezérlőn megtalálható a saját tartomá- 
nyának domain-partíciója - felhasználónevek, 
gépek stb... Minden adat, amelyet az Active 
Directory-UC-ban szerkeszthetünk, de csak a 
saját tartományából. 

Amennyiben bekattintjuk, hogy a tarto- 
mányvezérlő legyen GC is egyben, akkor tu- 
lajdonképpen a konkrét gépen található saját 
tartományi partíciója mellé lekerülnek rá a 
többi tartomány domain-partíciós adatai is, 
pontosabban azoknak csak egy részhalmaza. 
Értelemszerűen ez a részhalmaz a legfonto- 
sabb tulajdonságokat jelenti. A tulajdonsá- 
gok körét a Schema Admin konzolban lehet 
beállítani - de nem igazán ajánlott, tekintve, 
hogy minden bővítés növeli a replikációs for- 
galmat, a szűkítések meg előre nem látható 
problémákat okozhatnak. 

Térjünk vissza az 1. ábrára. Nos, ez a fel 
állás az, amelyet röviden csak a , szegény em- 
ber vízzel főz" mondással jellemezhetünk. 


Egy szerverünk van összesen, minden mun- 
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2. ábra. Mely tulajdonságok kerüljenek be a GC adatbázisába? 


ció tulajdonképpen a smarthost - 
így azért már sokkal érthetőbb ez 
Peto megkötés) 
ms-Exc 
ms-Exci Éd VR Tae va 
pair] Reálisabb szerepkörkiosztás 
ogy 
ProwG§ A 3. ábra szerinti már egy fok 
ms-Exci 
Prow.] . kal szerencsésebb - és a realitás- 
ms-Exc . .. 7. y y gi 
msexd  — hoz jobban közelítő - felállás: ha- 
mstxd  bárittis tartományvezérlőn van az 
He Exchangesszerver, de legalább már 
urportj 
e van mellette másik, dedikált tar 
"La 
en tományvezérlő is. Es igen, jól lát 
valityi 
aveyt juk, már telepítettünk külön gépre 
OueryH SJ 
avey! egy Edge Iransport funkciót is. 
Ouery- Kö j RGt Ek 
msExa Véleményem szerint ez a minimá- 
nstxe lis architektúra ahhoz, hogy egy 


rendszergazda felelősen üzemel 
tethessen egy Exchangerendszert. 
(Pontosítva: a Unified Messaging rendszer 
természetesen nem része a minimális archi- 
tektúrának, és nem is kötelező telepíteni.) 

Végül vizsgáljuk meg egy kicsit nagyobb 
szervezet felépítését is! 

Itt (4. ábra) már van minden, mi szem-száj- 
nak ingere: redundáns Edge Iransport szer- 
verek a DMZ-ben, dedikált Exchange- és DC- 
számítógépek, több Mailbox Server funkciót 
ellátó számítógép, Client Access Server és 
Hub Transport funkciókkal, egyik szerve- 
ren mindez kiegészítve Unified Messaging 
szerepkörrel is. Látható, hogy itt már több te- 
lephelyünk van, de az is látható, hogy ha ter- 
vezünk az Active Directory-sitera Mailbox 
Servert, akkor kötelezően tennünk kell mellé 
Hub Iransport szervert és erősen ajánlott a 
Client Access szerepkör is. 

Megjegyzés: az Edge-szerverek redundán- 
sak ugyan, de ez nem valamilyen cluster-meg- 
oldással érhető el, hanem csak DNS round 
robinnal. 

Persze nem merítettük még ki az összes le- 
hetőséget. Létezhetnek nagyobb szervezetek, 


ahol érdemes lehet egy szerverre még keve- 
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sebb funkciót telepíteni. Sőt, amennyiben 
gyors gépeink vannak gyors hálózati kapcso- 
lattal, akár azt is megtehetjük, hogy minden 
egyes funkciót külön szerverre telepítünk. A 
teljesen szétszórt rendszernek meglesz az az 
előnye, hogy egy-egy gép meghibásodása csak 
egy funkciót fog érinteni - cserébe persze a 
korábbi gépen belüli adatforgalmat kivisszük 
a gépek közötti térbe. 


Gyakorlati tanácsok a szerepekhez 
Az elméleti megfontolások után nézzünk né- 
hány gyakorlati előírást: 

a A Unified Messaging funkció nem létez- 
het önállóan, bármennyire is csak erre a 
funkcióra lenne szükségünk. Az organizá- 
ciónak tartalmaznia kell mellette az Edge 
Iransport szerepkör kivételével mindegyi- 
ket. (Viszont a Unified Messaging szerep- 
kör bátran elhagyható, ha nincs rá szüksé- 


günk.) 
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3. ábra. Reális szerepkörkiosztás 


a A Unified Messaging szerepkör virtuális 
környezetbe nem telepíthető. 

n Clusterbe kötött Exchange 2007-szervere- 
ken csak Mailbox Server szerepkör lehet 
- minden mást ledobnak magukról. 

a Amennyiben külön szerverekre telepítjük 
az egyes funkciókat, a következő telepítési 
sorrend az ajánlott: 

1. Client Access Server szerepkör, 

2. Hub Iransport Server szerepkör, 

3. Mailbox Server szerepkör, 

4. Unified Messaging Server szerepkör. 

Az Edge Iransport szerepkört ellátó gép 
független a tartománytól, gyakorlatilag bár- 


melyik fázisban üzembe helyezhető. 


Telepítés — második nekifutás 
UPpgrade vagy tiszta telepítés? Első ránézés- 
re az upgrade tűnik sokkal bonyolultabb- 


nak, de igazából nem annyira az: nem létezik 
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ugyanis olyan út, hogy in-place upgrade. Az 
egyedüli lehetséges mód az organizáció átállí- 
tására az, hogy beteszünk egy új vasat - még- 
hozzá kizárólag 64 biteset -, majd erre felpa- 


koljuk az összes megkívánt funkciót, átmig- 





Service Delivery Location/ 
Client Service Location 












Edge Transport 
server 


de 
ÉJ Global Catalog server 


(4 











1 Hub Transport sérver 
Client Access server 
Mailbox server 







Internet 







Hub Transport server 
Client Access server 
Mailbex server 

Unified Messaging server 


Edge Transport 
server 





VoIP PBX or 
PBX/SIP Gateway 








Service Delivery Location/ 
Client Service Location 





1 Hub Transport sérvér 
Client Access server 
Mailbox server 
Unified Messaging server 









Tf Global Catalog server 
VoIP PBX or 


PBX/SIP 




















4. ábra. Több telephelyes organizáció 
szerepkörkiosztása 


ráljuk rá a postafiókokat, majd eltávolítjuk 
a régi Exchange-szervereket. Értelemszerűen 
úgy, hogy helyükre már az új, 64 bites vasa- 
kat tesszük be. 

Létezik még egy mód, ez pedig a migrá- 
ció: létrehozunk egy szűz címtárat, benne egy 
szűz Exchange 2007-organizációval, majd át 
migrálunk minden felhasználót, minden erő- 
forrást, illetve minden alkalmazást ebbe az 
erdőbe. (Esetleg bonyolultabb lelkű egyének 
megtehetik azt is, hogy csak a felhasználókat 
és a postafiókokat migrálják az új erdőbe, 
majd a két erdő között alakítanak ki interorg 
kapcsolatot. Hajrá!) 

Szamonita raz első c átslisszamásos — mód 
szer a szimpatikusabb, de nem mindig szub- 
jektív szempontok alapján kell döntenünk: 
vannak esetek, amikor csak migrációval ju- 
tunk egyről a kettőre. Két ilyen eset van: 

a Exchange 5.5 rendszerről szeretnénk Ex 


ekkor 


először létre kell hoznunk egy Exchange 


change 2007 rendszerig eljutni: 


2000/2003-organizációt, ebbe átmigrálni 
az Exchange 5.5-adatokat, " majd az relső 
módszerrel továbblépni az Exchange 2007- 


organizáció felé. 


ya 


a. Nem Exchange-rendszerről (például Notes, 
Groupwise) szeretnénk átállni Exchange 
ZOOT-otganizációra. 

A meglévő organizáció átalakításához ké- 
pest a szűz Exchange-organizáció kialakítá- 
sa már nem annyira nagy kaland. De azért 
unatkozni sem fogunk.... 

(Gyors megjegyzés: azzal azért legyünk tisz- 
tában, hogy ha új Exchange 2007-organizá- 
ciót hozunk létre, akkor abba utólag már nem 
léptethetünk be Exchange 2003-szervereket.) 

Előfeltételek. Mit szeretne a címtár és a 
hálózat? Alapvetően Windows Server 2003 
SPl-et. Konkrétabban: 

a A Schema Master szerepet hurcoló tar- 
tományvezérlőnek minimum Windows 
Server 2003 SP! szervernek kell lennie. 

a Minden Active Directory-site-on, ahová 
Exchangescszervert tervezünk, lennie kell 
egy Global Catalog funkciónak. Ennek a 
tartományvezérlőnek is legalább Windows 
Server 2003 SP! szervernek kell lennie. 

a "Abban a tartomanyban, ahol" najdokiad 
juk a setup /prepareLegacyExchangePer- 
missions parancsot (és ki fogjuk adni, ezt 
megígérhetjük), feltétlenül lennie kell egy 
olyan tartományvezérlőnek, amelyik leg- 
alább Windows Server 2003 SPI. 

Érdekes lehet, hogy miért ragaszkodik any- 
nyira a címtár ehhez a verzióhoz. Nem titok: 
a Windows Server 2003 SPI szerverben van 
egy olyan funkció, hogy Service Notification. 
Ennek az a szerepe, hogy amikor valami vál- 
tozás történik a címtárban, erről értesítést 
küld az egyes szolgáltatásoknak. A legtöbb 
Exchange 2007-szolgáltatás intenzíven ki is 
használja ezt a lehetőséget. 

Persze nem csak ennyi feltételről van szó. 
Jöjjenek a többiek! 

a Amennyiben nem angol nyelvű tarto- 
mányvezérlőt használunk, és szeretnénk, 
ha lenne OWA-nk az organizációban, ak- 
kor telepíteni kell a KB919166 cikkben 
említett foltot. 

am Az összes tartományban, amelyik részt vesz 
AZ OLDADIZACIÓDAJ Ka tATtOTÁNNYT TÜNNI KEiÓ- 
nális szintnek minimum Windows 2000 
natívnak kell lennie. 

an Amennyiben különböző Active Directory- 
erdők " "azaz organizációk —" között sze 
retnénk bizonyos szintű Exchange-kap- 
csolatokat, -átjárásokat létrehozni, akkor 
természetesen biztosítani kell az erdők 


megfelelő összekötését. Ez gyakorlatilag a 
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megkívánt forestforest trustok beállítását 
jelenti. (Esetleg érdekelhet valakit, mik 
lehetnek ezek a kapcsolatok. Nos, lehető- 
ség van hozzáférni - organizációk között 
- egymás fÍree/busy információihoz, ké- 
pesek lehetünk feladatköröket delegálni, 
hozzáféréseket engedélyezni a másik er- 
dő erőforrásaihoz - feltéve persze, hogy a 
trust ezt megengedi.) 

a Upgrade esetén nem lehet Exchange 5.5 
szerver az organizációban. Ez gyakorlatilag 
azt jelenti, hogy az organizációnak natív 
módban kell üzemelnie. 

x A DNS olyan precízen működjön, mint 
egy Svájci óra. 

a Végül mielőtt bármi komoly munkának 
nekiállnánk, ki kell preparálni a címtárat. 
Kipreparálni... könnyű ezt leírni, de a cím- 

tár azért csak nem vaddisznó - a preparálás itt 

egy kicsit komplikáltabb. Hogy pontosan mi 

az ehhez szükséges négy lépés, az a IechNet 

Portálon olvasható magyarul a http://tinyurl. 

com/wjyjd linken található cikkben. 


Hardverkövetelmények 

A termék csak 64 bites processzort tartalma- 
zó vason fut - és azok közül sem mindegyi- 
ken, csak az x64 alapú rendszereken (Intel 
EM64I, AMD64. Az Intel [tanium IA64 


platformja nem támogatott. 
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5. ábra. Telepítés — az tells nös 








A minimális memória mennyisége 2 giga- 
bájt, az optimális memória mennyisége pedig 
további 5 megabájt mailboxonként. (Érdemes 
azonban figyelembe venni, hogy a memória- 
előírások szerepkörönként változnak.) 

Ezenkívül legalább 1,2 gigabájt szabad te- 
rületre lesz szükségünk azon a partíción, 
ahová az alkalmazást telepítjük, valamint 
további 200 megabájtra a rendszerpartíción. 


A Unified Messaging funkció telepítésekor 
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további 500 megabájtot foglal minden egyes 
nyelvi csomag felrakása. 

A telepítéshez használt partíciók csak 
NITES formátumúak lehetnek. 


Szofiverkövetelmények 

Legalább Windows Server 2003 SPl-re lesz 
szükségünk, amin telepíteni kell a .Net ke- 
retrendszer 2.0-t, a Windows PowerShellt, 
valamint a Microsoft Management Console 
(MMO) 3.0-t. 

Fontos még hangsúlyozni, hogy a szerep- 
körök nagyon nem szeretik, ha egy szerveren 
vannak Network News Iransfer Protocol 
(NNIP) vagy Simple Mail Iransport Protocol 
(SMTP) szolgáltatással - ezeket el kell távolí- 


tanunk a telepítés megkezdése előtt. 
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Specífy the path for the Exchange Server installator 


fERPiogram FiestMicrosoítEzchange Server — Browse.. ] 
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6. ábra. Telepítés — szerepkörválasztás 


Kíváncsiságból kipróbáltam, mi történik, 
ha minden előkészítés nélkül végignyomkod- 
juk a telepítőt. Jó hír, hogy másodikra sike- 
rült is a teljes telepítés - értve ezen egy olyan 
teljesen szűz organizáció létrehozását, amely- 
ben egy szerveren volt a szükséges három 
szerepkör. 

Azért másodikra, mert a telepítési folya- 
matban létezik egy ellenőrzési fázis, az pon- 
tosan kidobta, mi minden nem stimmelt. 
Ezeket leírtam egy cetlire, majd korrigáltam 
- és innentől hasítottak is a bitek. Szintén jó 
hír, hogy semmit sem kellett foglalkozni az 
Active Directory preparálásával: a telepítő 
észlelte, hogy teljesen nyers címtár van alatta, 
és szó nélkül lezavarta mind a négy prepará- 
ciós folyamatot. (Iermészetesen ehhez az is 
kellett, hogy maga a címtár nagyon egysze- 
rű legyen: 1 erdő, 1 fa, 1 tartomány, 1 DC 
- mi pedig legyünk tagjai az Átyauristens 
csoportnak.) 

Éles környezetben azért nem javasolnám 


ezt a kamikáze-módszert. 
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Telepítés, végre. Feltehetően most már 
mindenkinek erősen viszket a keze, és mo- 
torikus mozdulatokkal tekergeti tokjában a 
telepítő-cédét. Igen, mostanra jutottunk el 
végre oda, hogy betegyük a cédét a meghaj- 
tóba, és beírjuk a bűvös szót: setup. Csak így, 
mindenféle kapcsoló nélkül. 

Első körben megjelenik néhány nem túl 
izgalmas képernyő: a telepítő észreveszi, 
hogy már van MMC3, .Net keretrendszer 
és PowerShell a gépen, feldobja a szokáso- 
san gyorsolvasással kivégzett licencrészlete- 
zést, megkérdezi, részt szeretnénk-e venni a 
hibabejelentési programban. Végül megkap- 
juk az első komolyabban kinéző képernyőt 
6. ábra). 

Itt dönthetjük el, hogy tipikus telepítést 
kérünke vagy testreszabottat. Az utóbbit a 
következő esetekben érdemes választani: 

a Ha magunk akarjuk meghatározni, hogy 
milyen szerepkört szeretnénk felrakni a 
szerverre. 

a Ha clusterbe kötött Exchange-szervert sze- 
retnénk telepíteni. 

n "Ta csak az adimimisztraciós konzolra van 
szükségünk. 

a Mindig. Igazi rendszergazda soha nem vá- 
laszt tipikus telepítést. 

A 6. ábrán azt láthatjuk, mit is takar a cus- 
tom opció. 

Jelen esetben épp egy Edge Iransport szer- 
vert fűztünk az organizációhoz. Látható az 
is, hogy a telepítő okos, nem hagyja olyan 
mixek kikeverését, amelyek egyébként sem 
élnének meg. (Például clusterbe kötni csak 
mailbox-cszervereket lehet - tehát itt szürke a 
checkbox. Ugyanúgy szürke a menedzsment 
eszközök telepítése is, mert ez az elem min- 
denképpen települ, ha akár csak egy szerep- 
kört is kiválasztunk.) 

Ha kikevertük az ízlésünknek megfelelő 
kombinációt, mehetünk tovább. Amennyiben 
szerepelt a koktélban a Mailbox Server sze- 
repkör, és ez az első szerver az organizáció- 
ban, akkor először is a telepítő bekéri az or- 
ganizáció nevét, majd következik egy roppant 
trükkös kérdés. 

Van-e Outlook 2007-nél korábbi kliens a 
hálózatban? Elsőre nem tűnik olyan sarkala- 
tosnak a probléma, pedig... Ezen a válaszon 
múlik az, hogy kelle Public Folder a szerver- 
re vagy sem. Az Outlook 2007 előtti kliensek 
ugyanis a fÍree/busy és az Offline Address 


Book információkat a hagyományos módon 





(ml€di x 


próbálják leszedni - márpedig ezek rend- 
szerfolderként a Public Folder adatbázisban 
Mannak 

Ha azt mondjuk, hogy csak Outlook 2007 
vagy annál frissebb kliensprogramunk van, 
akkor nem kapunk Public Folder adatbázist. 
De nem csak nyilvános mappánk nem lesz 
- akkor is hoppon maradunk, ha MAPLn ke- 
resztül szeretnénk elérni a mailbox-szervert. 
A szerver ugyanis blokkolja a MAPLelérést, 
amire egyébként is csak a régi klienseknek 
lenne igényük. 

Amennyiben meggondolnánk magunkat, 
és mégis szeretnénk MAPI hozzáférést, tele- 
píteni kell a későbbiekben egy Public Folder 
adatbázist - ez oldja a blokkolást is. 

Térjünk vissza a telepítési folyamathoz. 
Jelenleg ott járunk, hogy a telepítő éppen 
húzza a csíkot: ellenőrzi, hogy minden telepí- 
tési feltétel teljesülte. 

Amennyiben valami nem stimmel, megle- 
hetősen részletezve közli a program, hogy mit 
kell pótolnunk. 

Szerencsére itt minden rendben volt. 
(Mondjuk, egy Edge Iransport szervernél ez 
nem egy nagy mutatvány.) Mint a 7. ábrán lát 
ható, a 32 bites operációs rendszert már csak 
hivatalból is megszólta, elvégre ez egy nem tá- 
mogatott konfiguráció. 

Majd amikor nyugtáztuk — mi ís, ó ís , 
hogy minden rendben, akkor indul el a tele- 


pítés maga. 


CA Exchange Server 2007 Setup 


(Hl Introduction 
HI License Agreement 
IB Emor Reporting 
(1 Installation Type 
ma Server Role 
Selection 


Readiness Check: 

The system and server wil be checked to see whether Exchange is ready to be installed, 
Elapsed time: 00-00-37 

Summary: 1 items. 0 succeeded, 0 faded. 


38 Edge Transport Role Prereguisítes 
Status: Best practices update checking has completed. 
Elapsed Time: 00-00-37 


Kr ád 


ID Readíness Checks 


Select OrkC to copy the contents of thés page. 


c Back l Instal I Cancel I 





7. ábra. Telepítés — az előkészítési fázis ellenőrzése 


És itt van. Igen, megcsináltuk! 

Persze butaság lenne azt hinni, hogy ezzel 
vége is a telepítési folyamatnak. 

A telepítés ellenőrzése. A telepítés végén 
célszerű végignézni a folyamat során keletke- 
ző logfájlokat. Ez jelenti egyfelől a klasszikus 
event logokat, de az Exchange emellett gyárt 


két, kifejezetten bőbeszédű szöveges fájlt is: 


ya 
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Zsystem driveztxchangeSetuplogst ExchangesSetup.log, 
system driveztxchangeSetuplogst ExchangeSetup. 
msilog. 


Az utóbbi a telepítő fájlok kitömörítésé- 
nek folyamatát rögzíti, míg az előbbi a teljes 
telepítést. 

Volte már az olvasók között olyan személy, 
aki valaha is rá volt kényszerítve, hogy végig- 
olvasson egy ilyen logot? Eszméletlen munka. 
Nem véletlen, hogy az Exchange mellé cso- 
magoltak egy kis szkriptet is (Csystem drivexN 
Program FilessMicrosoftvExchangeXScriptsv 
GetSetupLog.ps1). 


Jd Exchange Server 2007 Setup 


Readiness Checks 

The system and servet will be checked to see whether Exchange is ready to be installed. 
Elapsed time: 00-01:01 

Summary: 1 items. 1 succeeded, 0 faded. 

38 Edge Transport Role Prereguisítes a 


Waming 
The 32-bit version of Exchange Server 2007 is not supported for production use. 


Elapsed Time: 00-01-01 


Select OC to copy the contents of this page. 
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8. ábra. Telepítés — az ellenőrzés eredménye 


A következő kombináció faszerkezetben 


kilistázza az összes hibaüzenetet a logfájlból: 


Get-Setuplog . cxAexchangesetuplogstexchangesetup.log . - 
error -Íree 


Ha eddig nem tettük, ellenőrizzük, hogy a 
korábban részletezett változások tényleg meg- 
történtek-e a címtárban. 

A telepítés végén akár 20(!) Exchange- 
szolgáltatás is felkerülhet a gépre a szere- 
pektől függően. (Elég jól sikerült elszakadni 
az Exchange 4.0 négy darab alapszolgálta- 
tásától.) Érdemes ezeket végignézni, hogy 
amelyik ,automatic"ra van állítva, tényleg 
elindulte. 

Edge/Hub transport szerverek esetén úgy- 
nevezett ügynökök (agentek) települnek a 
szerverre. Célszerű ezeket is ellenőrizni, hogy 
rendben létrejöttek-e. 

Ezek az ügynökök gondoskodnak egyfelől 
a higiéniai (antispam, antivírus) szabályok 
végrahajtásáról, illetve a különböző háziren- 
dek érvényesítéséről. 

Legvégül érdemes lefuttatni az Exchange 


Best Practice Analyzert is, ellenőrizendő, 


2 2 





hogy valóban minden rendben működik-e. 
(A program elérhető az adminisztrációs 
konzolból is.) 

Utómunkálatok. Nem, nem ez nem má- 
niákusság - egyszerűen csak képtelenség még 
elszakadni a telepítés folyamatától. Ugyanis 
attól, hogy fellapátoltuk a binárisokat, még 


nem lesz működőképes a rendszerünk. 


598 Exchange Server 2007 Setup 


(E Introduction 
HI License Agreement 
(HI Error Reporting 
(I Installatton Type 
nm Server Role 
Selection 


Completion 
fába feltapknaj Ssrvás lots ve EGerÜocos eke ESEK To close the wizard, céck 


Elapsed time: 00-14-54 
Successfuly installed. No errors. 


42 Copy Exchange Fides o 
Elapsed Time: 00.05-13 

38 Edge Transport Role 
Elapsed Time: 00-09-40 


Hl Readness Checks 
I Progress 
EB Comoleti 


Select CC to copy the contents of thés page. 
F Exit Setup and open the Exchange System Managert. 
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9. ábra. Telepítés — záró képernyő 


Ilyenkor még célszerű lefuttatni az úgy- 
nevezett Security Configuration varázslót, 
valamint mindegyik szervernél érdemes be- 
állítani a különböző jogosultság-delegációkat 
- azaz, hogy mely szerepköröket mely felhasz- 
nálói csoportok menedzselhetik. 

További teendők szerepkörönként: 
an Hub Iransport Server esetén: hozzuk létre 

és állítsuk be megfelelően a transzport jel 

legű szabályokat, illetve a házirendet. 
a Elemeztessük ki a levélfolyam útvonalát 

a Mail Flow Analyzer segédprogrammal. 

Gyártsunk egy külön postafiókot a karan- 


tén számára, majd rendeljünk ehhez egy fel 



















használót. 
Ele Acion Yew Hebp 
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10. ábra. Telepítés utáni munkálatok 


n Client Access Server esetén: engedélyezzük 
az IMAP4, POP3 protokollokat, amennyi- 
ben szükségünk lesz rájuk. Érvényesítsük a 


külsős kapcsolatokra vonatkozó biztonsá- 


gi megfontolásainkat (HTTPS, RPC over 

HTTP, autentikációk stb.). 

n Mailbox Server esetén: hozzuk létre a meg- 
álmodott adatbázis-szerkezetet, és kezdjük 
el felvenni/migrálni a felhasználói postafi- 
ókokat. Ezek után gondoljuk végig a back- 
up/restore folyamatokat. 

ax Edge Iransport Server esetén: konfigurál 
juk be a ADAM-et. 

Látható, van utómunkálatból is bőven. 
Nem is várja el senki, hogy fejből emlé- 
kezzünk mindegyikre: ha a konzolban a 
, Microsoft Exchange" folderre állunk, akkor 
a középső területen a , Finalize Deployment" 
fül alatt látható, hogy az adott szerveren mi- 


lyen munkálatok vannak még hátra. 


Szerepkörök módosítása 
Hozzáadás. Van egy működő rendszerünk. 
Egy idő után észrevesszük, hogy a szerepkö- 
röket nem igazán optimális módon osztottuk 
szét a szerverek között - szeretnénk egy kicsit 
átrendezni az organizációt. Berakjuk az első 
számítógépbe a telepítő-cédét, hogy bővítsük 
a szerveren a szerepek körét... és nem törté- 
nik semmi. 

Ez bizony kellemetlen. Az Exchange-szer- 
veren a szerepköröket utólag már nem le- 
het bővíteni. Legalábbis a grafikus felületről 
nem. De szerencsére a setup programnak 
van néhány kapcsolója, ezekkel elég sok min- 
denre rá lehet venni ezt a kedves binárist, 
amit a /? kapcsoló segítségével tudunk átta- 
nulmányozni. 

Eltávolítás. Igen, bármennyire is hihetet 
len, de előfordulhat olyan eset, hogy akár egy 
szerepkört, akár egy komplett szervert el sze- 
retnénk távolítani. A szerepkört eltávolíthat 
juk egyfelől a fenti setup parancs segítségével 
- de itt már használhatjuk a grafikus felüle- 
tet is, a következőképpen: 

Control Panel/Add-remove 


Microsoft Exchange Server/ Remove - ekkor 


Programs/ 


bejön a telepítő grafikus felülete. Kiválasztjuk 

az Exchange Maintenance módot, majd beje- 
löljük az eltávolítandó szerepköröket. 

Amennyiben az egész szerver eltávolítása 

a cél, akkor a fenti munkamenetet kell végig- 

csinálni, csak most az összes szerepkört - és 

az admin konzolt - kell kijelölni eltávolításra. 

Szerepkör nélkül pedig szerver sincs többé. 

Petrényi József 

(petrenyi.jozsef(oOsao.hu) 

SA0-Synergon, MCSE--M, MVP 


Microsoft TechNet 
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ÉEXCHANGE SERVER 
2007: MAGAS 
RENDELKEZÉSRE ÁLLÁS 


Bizonyos első találkozásokra egész életünkben emlékszünk 





— hasonlóképp izgalmas dolog egy új szerverszoftverrel való 
ismerkedés is —; többek között az előző verziókkal kapcsolatos 
tapasztalatok alapján várunk és — jó esetben — kapunk újdonságokat. 

kommunikáció különösen érdekes téma, manapság már majd" mindennel összefonó- ! jére a tranzakciónaplók továbbításával. Az 
A dik, és megkockáztatható, hogy a helyzet még tovább fog bonyolódni. Az Exchange- ! LCR elszállítja és újrajátssza - a mostantól 


szerver összetett adattovábbító, -kezelő- és -tároló rendszerként ezen a területen teszia ! 1 megabájtosra lefogyott - logokat a tarta- 


dolgát jó ideje, verzióváltásnál viszont automatikusan eszünkbe jut, 





lehete még tartalmasan újítani/ bővíteni rajta valamit. 


A TechNet Magazin többi cikkét átböngészve hamar rájöhetünk, 





hogy igenis lehet. 









E rövid fejezetben az Exchange Server 2007 magas rendelkezésre 






099! 


Storage Controller 


állási, a hibatűrést fokozó - online és offline - megoldásait tekint 


jük át; és ezen a speciális területen is találkozhatunk figyelemre mél 





tó érdekességekkel. Active copy of 


Storage Group 


Passíve copy of 
Storage Group 


( JLogs ()]DB 


Magas rendelkezésre állás esetén az ember azonnal a különféle 
fürtözési megoldásokra asszociál. Ilyenkor nagy költségvetésű kon- 
figurációkat és bonyolult installációkat vizionálunk, az egész ügy 
egy picit misztikus ködbe is burkolózik; százalékok, kilencesek, fu- 
ra szavak és rövidítések (downtime, SLA, SAN stb.) kerülnek elő. Replication of Log files 
Remélhetőleg e cikk arra is jó lesz, hogy kiderüljön: ha ismerjük a 
szoftvereink adta lehetőségeket, egy átgondoltan kialakított rend- A Local Continuous Replication működése 





szerrel is rengeteg lehetőség nyílik a rendelkezésre állási szint eme- 


lésére, anélkül, hogy az II-büdzsé jelentős részét elvinné az extra hardver és support. Erősen ! lék adatbázison, így előállít egy teljes érté- 


leegyszerűsítve a kérdést, két dologra kell figyelni: 1. Ne romoljon el, ami fontos, 2. Ha mégis, ! kű másolatot a produktív adatokról, amire 
nagyon gyorsan helyre lehessen állítani. egy adminisztratív lépéssel bármikor át lehet 
Lássuk akkor, mire is képes az új Exchange! kapcsolni. Mindezek mellett az LCR a ha- 


gyományos backup-megoldásokra is jótékony 
Folytonos helyi replikáció (Local Continuous Replication, LCR) hatással van mert csokkenthetóráa napi teljes 
Érdemes az LCR-rel kezdenünk áttekintésünket, mivel ehhez a megoldáshoz nincs szükség ! mentések száma, másrészről a mentőszoftver 
fürtözésre. Exchange-szerverünk mostantól hajlandó lesz másolatot készíteni - és fenntartani ! dolgozhat a másolattal, meghagyva az értékes 


- egy tárolócsoportról vagy adatbázisról ugyanannak a kiszolgálónak egy másik diszkítömb)- ! diszk [/D-t az éles adatbázis alatt. Ettől füg- 
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getlenül a már megszokott offline ! paralt, "katasztrólatúró kontt 
mentéseinkre is szükség lehet, mi- BZALSNR BET KN TKÉT gurációk, egyszerűbb telepítés 
vel ai LCR nem biztosít 24x7-es Standalone () witness File Share és az LCR-nél már említett 
Ce eesz ást lbeldauli Exchange 2007 EZT RÉNKÉS ETT TT TAT ei szsjtíje j es 
rendelkezésre állást (például szer servers 68 : mentéssel kapcsolatos pozitív 
verhiba előfordulásakor). Ezekre 2 ; hatások. 
az esetekre nézünk megoldásokat £ Máz végy. c 8 p.s) Befejezésül nézzük át, hogy 
a továbbiakban. Active Directory MPE Tee Bat att át" öüenés Hit meny telnet, aki a CCER mek 
Domain Controller a Switch lett dönt: egy tárolócsoport 
.. s. aZ z Global Catalog 1 ; 
Fürt közös tárolóval DC1 ! ban csak egy adatbázis lehet 
(Single Copy Cluster, SCC) i (iz Eozeléeimee Sera 1007 mee 
ZS égy EtÜtközött smanlbox Mailbox server c d Public network [A Mailbox server ximum 50 tárolócsoportot ke- 
keze LE Active Node E S Passive Node D) ThÉst bb 
szerver közös diszkrendszerrel. Ez NODEA Jem t geza tem eteztENnEN NODEB zel), nem futhat ugyanebben a 
tulajdonképpen az Exchange elő- fürtben sem az Exchange elő- 
ző változataiban már használható E2K7CCR ző verziója, sem SOL-szerver 
shared-nothing modell, amelyben TERET ET ELSE EST ei és nyilvánosmappa-radatbázist 
a fürt bármelyik tagja hozzáférhet Storage Group Storage Group is csak korlátozások mellett le- 
a tárolócsoportokhoz, de egyszerre § Lada § DB Oo (oca Oo DB het CCRfürtben tartani. 
csak az egyikük. Változások azért 
ebben az üzemmódban is vannak, A (Iuster Continuous Replication minden ellen véd Mentés 
például az Exchange Server 2007 Akár fürt, akár nem, előbb 
csak az aktív/passzív SCC-összeállítást támo- ! MSClustercsszerviz hibatűrési képességeivel. ! vagy utóbb úgyis elő kell venni a mentésein- 
gatja, hozzátéve, hogy az előző verziókban is ] Folyamatos rendelkezésre állást biztosít ada- ! ket. A már ismert és bevált lehetőségeket fus- 


ez volt az ajánlott konfiguráció. Az SCECmód 1! tokban és szolgáltatásokban SPOF 
Exchangescszerverünk szolgáltatásainak közel ! nélkül, mivel nincs egy közös diszk- 


folyamatos rendelkezésre állását biztosítja, ! rendszer a fürt tagjai között (mint 


s Mailbox Server 


de továbbra is érzékeny marad a közös táro- I a hagyományos failover fürtökben, S LESSEE ELLA Cai 
,  Offers Data Availability 


ló hibáira. Így a fürt tagjainak számától füg- ! lásd SCO). 


" — Non-Shared Storage (mitigation of single point failure) 


getlenül mindig lehet SPOF (Single Point of A CCR az MSClusterszerviz 000 ozszőáátáazzytatámsá 
" " Based on Windows Clustering (auto-failover) 
Failure) a rendszerben, ellentétben a követke- ! Majority Node Set (MNS) módját TTV NTLETÉSa 
z 7. les § § 4. " "Local Continuous Replication (LCR) 
ző pontban tárgyalt CCR-megoldással. használja, mivel így lehetséges kö- 00011 TEG NBBÁTAOTÁNKÁNNRORORTRBBBB 
zös diszkrendszer nélküli, különálló LES ELET 
0.0 e e ff e/7 3 E ve pe 8 E B hú 61 éj el ee Data storage Options 
Folytonos fürtbeli replikáció szerverekből álló fürtöt kialakítani. a TE EREÉZEKTAB 
(Cluster Continuous Replication, CCR) ! Tehát részben az operációs rendszer ÁG EÉKA 
" " Based on Windows Clustering 
A ECR kombimnaljasaz Exchamse Server ZOOTNERYAESESTESÉSE E hogy ragot úm els LR E LKEZÉS 





naplószállítási és -újrajátszási lehetőségét az ! érhető legyen a fürt tagjain, emel zzzázáak 


lett az Exchange Kendelkezésre állási lehetőségek az Exchange 2007-ben 








Mailbox server Mailbox server 
Active Node Passive Node 


4 


replikációs — szervi 


ze intézi saját adatainak to- ! suk át gyorsan: hagyományos online mentés 





vábbítását. A csapat harma- ! és a Volume Shadow Copy Service. 
dik állandó résztvevője lesz Az első az Exchange ESE Backup APL 


egy fürtön kívüli kármentő ! ján keresztül, a második az operációs rend- 


Private Network 


transport dumpster (,ma- ]! szer VSS-szervizével érhető el. Mindkettőhöz 


Shared storage gyarul": egy Hub Iransport I használható a Windows Server 2003 beépí 
array szerver), amelynek az eset ]! tett mentőszoftvere, hozzátéve, hogy ,igazi" 
; leg előforduló átállás során ! Exchange-VSS-mentéshez más gyártó megol 
keletkezett adatok védelme ! dásainak alkalmazásra lesz szükség. 


Logs DB lesza teladataso Mindezeket A mentési típusok nem változtak: Full, 


figyelembe véve e megoldás ! Copy, Incremental, Differential. A választás 











Oueue több előnye is tisztán látszik: ! alapja lehet, hogy mentsünk-e mindent vagy 

j nincs SPOF, nem kell kö- ]! csak a változásokat, illetve, hogy a mentés vagy 
—— Storage connection to Active Node zös diszkrendszer, és sima 1! a visszaállítás folyamata legyen-e gyorsabb. 

——m Storage connection to Passive Node széner ASE eleje Sen ÜUgyanakkonsaz iss igaz iinogy teljessadat 

; tünk tagokat. Az eredmény: ! vesztés ritkán fordul elő, inkább elemi ada- 

A Single Copy Custer megoldás kisebb költség, fizikailag sze- ! tokat kell helyreállítani, és ezt az Exchange 
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lett: a törölt elemek/mailboxok visszatartása 


mostantól alapértelmezés szerint 14/30 na- 


eddig is támogatta megfelelő beállítások mel 





Exchange-változatokban ez egy recovery stor- 
age group, egy, az eredetivel megegyező nevű 
vagy egy azonos adminisztratív csoportba 


tartozó szerver lehetett. (Mivel 









Exchange Server 
Storage group 


Dial tone 
database 


r 
Mailbox 


Recovery storage 
group 


Mailbox database 
(recovery) 


Mailbox 
(backed-up content) 


Active Directory 


az Exchange Server 2007-ben 
már nincsenek adminisztratív 
csoportok, és a hozzáférések 
kezelése univerzális biztonsá- 
gi csoportokon keresztül törté- 
nik, ez a korlátozás eleve meg- 
szűnt.) 
Végeredményben egyetlen 
megkötés maradt, az eredeti 
és az alternatív szervernek azo- 
nos Exchange-organizációhoz 
kell tartoznia. Fontos a klien- 
sek kezelése az adatbázis áthe- 
lyezése után, az OWA felüle- 


tén érkezőket automatikusan 





átirányítja a rendszer a cím- 





A Storage Groupok helyreállítási lehetőségei 


pig lehetséges - vagy tovább is, ha szükséges 
-, figyelembe véve, hogy az adatbázisok mére- 
tébe ezek az elemek is beleszámítanak. 
Összefoglalva, ami fontos a mentésekkel 
kapcsolatban: mennyi helyi és/vagy hálózati 


erőforrást visz el, mennyi ideig tart, milyen 


tár segítségével, Outlook 2007 

használatávalra felhasználókat 
csatlakozásukkor - a mail-profiljuk módosí- 
tásával - az új helyre továbbítja az Exchange 
Autodiscover szervize. Régebbi Outlook-ver- 
ziók esetén manuális módosítás szükséges, 
ha a szerver neve megváltozott. Jó tudni, 


hogy at hotdozítakóságtesak a mnaiboszadat 





gyakran kell ismételni. 
Abból kiindulva, hogy 07 
folyamatos üzemet terve- 
ú Mék L/A 
zünk, optimális megol I 
(El Introduction 
dásként a hagyományos EI License Agreement 
Mek ot 5 IE Error Reporting 
mentési eljárások kombi I iratáláton Type 
nálhatóak az előző bekez- sség Eee 
désekben tárgyalt kétféle kepes ott Check 
Ld Progress 
folytonos replikáció vala- (1 Completion 


melyikével. 

Bár mindenkinek a sa- 
ját, személyes információi 
nak elvesztése a legkriti- 
kusabb, a teljes rendszer 
fenntartásának szempont 
jából fontos a komplett 


adathelyreállítási  proce- 








dúrákat is rögzíteni a ka- 
tasztrófa-elhárítási — terv- 
ben. Az Exchange Server 


2007 ezen a területen is nyújt újat. 


Hordozhatóság 
Új lehetőség az adatbázisok hordozhatósá- 
ga, amely lehetővé teszi, hogy azokat egy 


másik szerveren el tudjuk indítani. Az előző 
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Exchange Server 2007 Setup 


! 36T  EdgeTransport Role 





Server Role Selection 

Select the Exchange Server Roles you want to install on this computer: 

af [MaiboxRide CT Description ——————mmummvpEr 

É The Exchange Management T o0ls provides 

a!  CientáAccess Role the management tools needed to configure 
and manage Exchange Server, 


Ex Hub Transport Role 
án Urified Messaging Role 








Au Active Clustered Mailbox Role 
aa! Passive Ciustered Mailbox Role 





Disk Space Állocation 
Disk space reguired: 0.0 MB 
Disk space available: 9334.6 MB 


23 Tf Management Tools 











Specify the path for the Exchange Server installation 


[E:4Program FilesAMicrosoftt Exchange Server Browse... j 


(elk ] men ] 


Már telepítéskor is kiválaszthatjuk a clusterezést 


bázisokra vonatkozik, mivel a public folder 
adatbázisok hozzáféréseik kezelésében, repli- 
kációjuk során közvetlenül kötődnek egy bi 
zonyos Exchangesszerverhez. 

Szorosan kapcsolódik a hordozhatósághoz 


az úgynevezett dialttone helyreállítási módszer 


ke 


Gyors ismétlés: Majority Node Set 


(MNS) 





A W2K3-ban megjelent új fürtözési típus, amiben 
nincs szükség egy közös diszkrendszerre a tagok kö- 
zött. Mindenki maga intézi a gvorum adatainak táro- 
lását, a Custer-szerviz pedig lerendezi annak repliká- 
cióját. Így aztán földrajzilag szétszórt, iletve. olcsóbb 
szerverek is fürtözhetők. (Az alkalmazás adatait 
viszont nem replikálja az Microsoft Cluster Service, 
azt oldja meg valaki más.) Eredetileg páratlan szá- 
mú taggal lehetett kialakítani, hogy egy esetleges 
tudathasadásnál az egyik tagcsoport nagyobb legyen 
(lehessen majority). Windows Server 2003 $PI-re, és 
R2-re van egy 921181-es számú hotfix, ami után már 
lehet kéttagú MNS-fürtöt csinálni (például Exchange 
Server 2007 alá), ekkor kell viszont egy File Share 
Witness (harmadik, független szerver), amelyik szük- 
ség esetén voksol az aktív tag mellett. 





is. Tegyük fel, hogy bekövetkezett, amire senki 
sem vágyott: leállt a levelezőszerver. Ilyenkor a 
rendszergazdáknak legkevésbé sem hiányoz- 
nak a felhasználók (plusz ingerült főnökök) 
folyamatos jelzései, miszerint úgy tűnik, nem 
megy a levelezés. Iehát két fontos feladat van: 
lehessen küldeni/fogadni üzeneteket, ha a ré- 
gebbi adatok átmenetileg nem is érhetők el a 
szerveren, és emellett a lehető leggyorsabban 
álljon helyre megszokott környezet. 

A hordozhatósággal itt is javulnak az esé- 
lyek: készíthetünk a felhasználóknak egy 
új, üres mailboxadatbázist, így folytathat 
ják külső-belső levelezésüket (cache-elt módú 
Outlookkal még a régebbi üzeneteiket is el- 
érik), amíg az informatikai csapat nagy sebes- 
séggel visszaállítja a régi adatokat egy reco- 
very storage group segítségével, amit utolsó 
felvonásként összefésülünk a menet közben 
keletkezett új adatokkal. 

A procedúra alatt a felhasználók átirá- 
nyítása az előző bekezdésben vázolt módon 
természetesen itt is megtörténik, mi pedig 
reménykedünk, hogy ez a kis kaland nem 
érinti a negyedéves bónuszunkat. 

A felvetett témákkal kapcsolatos továb- 
bi érdekes részletek találhatók a http:/www. 
microsoft.com/technet/prodtechnol/exchange/ 
el2k7help linken az , Operations - High Availk 
ability" bekezdésre kattintva. 

Ország Tlamás 
MCSE--S--M, MCT. (tamascxedupro.hu) Számalk 
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MIKOR VÁLTSUNK 
64 BITRE? 


Rengeteg a tévhit a 64 bites rendszerekkel 











kapcsolatban. Például ha ma valaki 64 bites 
hardvert vásárol, rögtön 64 bites operációs 
rendszert tesz rá. Biztosan jó döntés ez? 


hogy folyamatosan nő az igény az egyre gyorsabb és nagyobb tárkapacitással rendel 
kező számítógépek iránt, újabbnál újabb ötletekkel állnak elő a hardvergyártók. A 64 
bites technológiák már igencsak régen megjelentek a nagyobb szerverhardverek pia- 
cán: nagyobb mennyiségű megcímezhető memóriaterületet kínáltak, valamint a sebességet is 
növelték azáltal, hogy egy utasítással több beérkező adaton végeztek el műveleteket. Azonban 
ezek többsége a mai hardverekkel és 
szoftverekkel nem volt kompatibilis, 
mivel teljesen újszerű utasításkészletet 
és módszereket használtak. Az egyik 
ilyen versenyző az Intel [taniumja. 
Eleinte nem örvendett hatalmas 
népszerűségnek ez az új architektúra, 
hiszen minden alkalmazást teljesen új- 
ra kellett hozzá írni (beleértve az ope- 
rációs rendszereket is), azonban ma 
már megtalálta a saját közönségét, és 
sokan választják ezt a legnagyobb telje- 
sítményt igénylő alkalmazásaikhoz. 
Ahhoz, hogy megértsük a 64 bit 


másik fejlődési irányát, fontos kiemel 


A 64 bites Intel Itanium 


ni: ekkor következett be az a pont 
a hardverfejlődésben, amikor rádöb- 
bent a teljes iparág, hogy nem lehet tovább növelni a processzorok frekvenciáját a sebesség to- 
vábbi növelése érdekében. Ekkor az AMD előállt saját 64 bites architektúrájával, az x64-gyel 
- ami kompatibilitást ígért a korábbi hardverekkel és szoftverekkel is. 


x6ó4 


Gondolkodjunk el egy kicsit, mit is jelent ez! Nyilvánvalóan nem használ olyan újszerű utasí- 
táskészletet, mint az Itanium. Viszont 64 bites. Biztosan sokan emlékeznek még arra, milyen 
óriási jelentőséggel bírt a váltás a 8-ról 16-ra, vagy a 16-ról 32 bitre. De miért is? Mert több cí- 


mezhető memóriára és tárhelyre volt szükségünk. Volt ezen kívül más újdonság is a korábbi 


ya 





TES E 
AS 


átállásokkor? Igen, optimalizálták a procesz- 
szor belső felépítését. Egyet elárulhatunk: ez 
utóbbi most, a 64 bit esetében nem sikerült 
számottevően. 

Nem kell sokat gondolkodni azon, hogy 
akkor mégis miért volt ennyire fontos az x64 
megjelentetése, ha tulajdonképpen az átlag- 
felhasználók számára csak annyit ígért, hogy 
4 gigabájtnál több memóriát is használhat 
nak. Ekkor már eltelt néhány év, hogy igazán 
új, mindennél jobb vagy gyorsabb processzor 
nem jelent meg a piacon, és az emberek nem 
tudták eldönteni új gép vásárlásakor, hogy 
melyiket vegyék meg a közel egyforma árú és 
teljesítményű versenyzők közül. 

Viszont a számokat mindenki ismeri. ,A 
64 több, mint a 32, biztosan jobb, ráadá- 
sul kompatibilis..." - gondolhatták sokan, és 
elkezdték vásárolni az AMD processzorait. 
Nem meglepő módon az AMD ekkor jelen- 
tős növekedésnek indult. 

Az sem meglepő, hogy az Intel is kihoz- 
ta ezek után EM64I processzorait (gyakor- 
latilag kénytelen volt), ezek ugyancsak az 
AMD -féle 64 bites megoldást használták. Az 
AMD64 és az Intel EM6G4T chipjeit hívjuk 
azóta gyűjtőnéven x64-nek, hiszen ugyanarra 
az alapra épülnek mind a ketten. Az x64 gya- 
korlatilag időt nyert a hardvergyártóknak, 
hogy kidolgozzák az új típusú, többmagos 
processzorokat, de addig is újat tudjanak ad- 
ni a vásárlóknak, még ha nem is kaptak sok- 
kal többet a pénzükért. A marketing bevált. 

Arról van tehát szó, hogy talán kicsit ko- 
rán erőltették rá a piacra azt, amire még 
valójában nem volt szüksége. Viszont mivel 
hamarosan tényleg szükség lesz a 64 bites vál 
tásra, már nem volt értelme a szoftvergyár- 
tóknak sem visszakozniuk, hiszen pár éven 
belül tényleg minden otthoni felhasználó és 
szerver eléri a 4 gigabájtos határt. 

Tudva a technológia gyengéit, próbáljuk 


meg mégis kihozni belőle azt, amit lehet! 


Mire is jó az xó4? 

Korábban, ha 2-3 gigabájtnál több memó- 
riát szerettünk volna használni egy x86-os, 
windowsos gépen, már trükkökhöz kellett 
nyúlnunk (például a PAE és/vagy a /3GB 
kapcsolóhoz), de még így sem mehettünk 64 
gigabájt fölé, és ez a megoldás sem volt töké- 
letes. Az x64 segítségével elhárul az akadály, 
a határ a csillagos ég (konkrétabban: most 


8196 gigabájt, de ez még növelhető lesz). Ez 


Microsoft TechNet 
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nagy adatbázisok, nagy terheléssel futó web- 
farmok és lekérdezéseket kiszolgáló rendsze- 
rek esetében jelentős segítség, hiszen minden 
maradhat a memóriában, több lekérdezést és 
felhasználót tudunk egyszerre kiszolgálni - 
vagyis tudunk fölfelé skálázódni egy számító- 
gépen belül is. 

A sebesség is nőhet bizonyos esetekben, 
mivel a 64 bites rendszereken a procesz- 
szor regiszterei is 64 bitesek, ami például a 
nagy pontosságot igénylő lebegőpontos szá- 
mításokon sokat tud gyorsítani. Mikor jó ez 
nekünk? A mérnöki munkát segítő CAD/ 
CAM-alkalmazások, a 3D-renderelés, vala- 
mint képfeldolgozó és néhány tömörítőprog- 
ram, valamint egyes szerverszoftverek képe- 
sek ezt kihasználni, de a szoftvernek külön 
támogatnia kell a 64 bites natív működést. 
Ez azt jelenti, hogy a szoftver bináris állomá- 
nyainak natív 64 bitre fordítva kell lenniük 
(nem is indulnak el 32 bites rendszeren). A 
hagyományos 32 bites alkalmazások azonban 
nem lesznek gyorsabbak akkor sem, ha alat 
tuk tényleg ott egy 64 bites operációs rend- 
szer és maga a 64 bites hardver. 

A szakmai teljesség kedvéért azt azonban 
meg kell említenünk, hogy a 32 bites alkal 
mazások egy speciális esetben tudnak profi 
tálni a 64 bites rendszer nyújtotta előnyből 
még abban az esetben is, ha az alkalmazás 
nincs optimalizálva az új futtatókörnyezetre. 
Ez akkor következhet be, ha párhuzamosan 
kell futtatnunk két vagy több olyan 32 bites 
alkalmazást, amelynek eleve 2-2 gigabájt me- 
móriára van szüksége. Mivel a 64 bites archi- 
tektúrán minden 32 bites alkalmazás önálk 
lóan lát egy legfeljebb 4 gigabájtos memória- 
területet, így ha hardverünk képességei azt 
megengedik, akkor akár két 32 bites alkalma- 
zás párhuzamosan futva, használhat 3-3 gi- 
gabájt memóriát. Ez elképzelhetetlen egy 32 
bites rendszerben, még trükközésekkel is. 

Ha már új architektúránk van, amire 
úgyis újra kell fordítani az alkalmazásokat 
(ha újraírni nem is kell), miért ne követek 
hetnénk meg néhány újdonságot alapköve- 
telményként? Elvégre van egy-két hasznos új 
biztonsági technológia, például a DEP (Data 
Execution Prevention) és az, hogy 64 bites 
Windowsokkal csak aláírt drivereket tölthe- 
tünk be Kernel módba. Ha már úgyis újra 
fogják fordítani a szoftver: és driverfejlesztők 
a kódjukat, legalább teszteljék le azt is, hogy 


ezeknek az igényeknek is jól megfelelnek-e! 
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Ezzel véget ér a 64 biten a DEPinkompatibi 
lis és a hibás kernel módú driverek korszaka, 
ugyanis a 64 bites Windows Vista esetében 
mind a DEP, mind a driver-aláírás kötelező 


érvényű. 


Mi a baj vele? 

Az imént láthattuk, hogy csak speciális alkal 
mazások és terhelések nyernek a 64 bit hasz- 
nálatával. A 32 bites szoftverek pedig a 64 bi- 
tes Windows WoW (Windows on Windows) 
alrendszerének köszönhetően működnek. Ez 
az emulálóréteg fordítja át a 32 bites utasítá- 
sokat és címzéseket olyanná, hogy 64 biten is 
megfelelően működjenek. Ez azonban akár 
mennyire kicsit is (egy százalékon belül mo- 
zog az esetek többségében), de lassít a 32 bites 
kód végrehajtásán, de messze nem annyira, 
mint az [tanium alapú 64 bites rendszerek 
32 bites ,kompatibilitási" rétege. Külön ér- 
dekesség, hogy a 32 bites Windows XP is 
használt egy másik, régebbi WoW-ot 16 bites 


alkalmazások futtatására a 32 bites rendsze- 
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kompatibilis - megvalósítani már sokkal ne- 
hezebb. A 32 bites driverek, illetve a kernel 
szinten futó kódok esetében a WoW ugyanis 
nem működik. Ez azt is jelenti egyben, hogy 
azok a hardvereink, amelyekhez csak 32 bi 
tes driver érhető el, nem fognak működni 64 
bites operációs rendszeren (gondoljunk itt a 
régi nyomtatókra, scannerekre). Sajnos szám- 
talan olyan alkalmazás is van, ami hardver- 
közeli hívásokat használ, és emiatt működé- 
sük nem emulálható ezekkel az eszközökkel. 
Összefoglalva: igaz, hogy maga a processzor 
tökéletesen futtatja a 32 bites alkalmazásokat 
- vagyis 64 bites vasra telepíthetünk 32 bites 
operációs rendszert, és nem lesz semmi kom- 
patibilitási gondunk, bár 64 bites alkalma- 
zások sem fognak menni, és a 64 bit semmi 
előnyét nem tudjuk így kihasználni. Az már 
sajnos nem igaz, hogy 64 biten futó operá- 
ciós rendszeren gond nélkül elférnek egymás 
mellett a 32 és 64 bites driverek. 

Az utolsó nagyobb probléma ennek a kö- 
vetkezménye, de a fejlesztőket sújtja: újra 


kell írni minden alkalmazást 











- vagy legalább fordítani 64 
bitre is -, és a meglévő 32 bi 
tes alkalmazásokat is tesztelni 
kell a WoW-ban. Erre jó példa 
a Symantec víruskeresője, ame- 
lyik 8-as és 9-es 32 bites szériája 
nem fut megfelelően a WoW- 
ban. A Symantec ezt követően 
nem az elegáns utat választot 
ta - hogy készít egy natív 64 
bites víruskeresőt -, hanem a 
meglévő 32 bites víruskeresőjét 
készítette fel a WoW-ban való 
futásra. 
Vagyis minden szoftvert 
tesztelni kell 32 és 64 biten is, 
ráadásul mindkét verzióhoz tá- 
mogatást is kell adni. Ez jelen- 
tős pluszmunkát jelent, és még 


sokan nem szánták rá a szüksé- 





SES ENELOTAt. 





Az Intel legújabb, kétmagos, 64 bites processzora, a Core 2 Duo 


reken. A lényeg: aki azt várja, hogy meglévő 
32 bites alkalmazásai gyorsabbak lesznek 64 
bites operációs rendszeren és hardveren, az 
lehet, hogy pont az ellenkezőjét fogja tapasz- 
talni, még ha csak kis mértékben is. 

A nagyobb sondázonbansáz, hogy  túlsáe 


gosan könnyű azt mondani valamire, hogy 


Valljuk be, ezek azért nem ak- 
kora meglepetések, ehhez hason- 
lót majdnem minden generációváltáskor átél- 
tünk már. A lényeg, hogy mi magunk alapo- 
san és nagyon körültekintően járjunk el, ha 
generációváltásra adjuk a fejünket, meg kell 
találnunk azt az időpontot, amikor érdemes 
váltanunk saját gépünkkel vagy éppen az [[- 


infrastruktúránkkal. 
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Fontos megjegyezni azonban azt is, hogy 
nemcsak a túl korai, de a túl késői átállás is 
sok kényelmetlenséggel jár, ezért nagyon fon- 


tos a megfelelő időben lépni. 


Ha 64 bites hardvert vettem... 
Mikor telepítsünk 64 bites operációs rend- 


szert egy számítógépre? Kizárólag akkor, ha 

az általunk "futtatandó "alkalmazások vagy 

szerverszofítverek mindegyikére igaz az aláb- 

biak állítások valamelyike: 

m 32 bites szoftver, aminek nincs natív 64 
bites verziója, de gond nélkül működik 


64 biten is a WoW-on keresztül, 


abban, hogy a számunkra kritikus ralkalma 
zások Lesetleg játékok) és driverek megfele- 
lően működnek. Ha biztosak vagyunk ab- 
ban, hogy minden számunkra fontos szoftver 
megy 64 biten, akkor aggodalomra nincs 
okunk, de teljesítményjavulást ne várjunk, 
nem lesz, vagy ha igen, minimális, és csak né- 
hány alkalmazásra lesz jellemző. 

Ha x64 alapú szervert veszünk, gondoljuk 
át, milyen szerverszoítvereket szeretnénk fut 
tatni rajta. Ha a szerverszoftverből nincs na- 
tív 64 bites változat, ne tegyük fel a 64 bites 


operációs rendszert se, inkább maradjunk a 





és az esetleges minimális teljesít 


ménycsökkenés sem jelent prob- 
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lémát számunkra. 

n Natív 64 bites alkalmazás, és 
vagy nincs belőle 32 bites válto- 
zat, vagy szükségünk van több 
memória hatékonyabb használa- 
tára (példáuljnagy adatbázisra), 
és szükségünk van a lebegőpon- 
tos műveletek gyorsítására. 

A fent említetteken kívül még 
két szempont segít dönteni: 

a Minden hardverkomponenshez 
kell lennie 64 bites drivernek, 
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különben nem tudjuk használni. 
(ábasztalátuieázhogysaz üjöbe 
nan szállított brand szerverekhez 
a gyártó minden, a dobozban levő 
hardverelemhez biztosítja a 64 bi 
tes drivert. Meglepetés ettől még 


érhet minket, tapasztalataink sze- 


hi £z 





simultaneous 
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AMD Opteron" Processor 


with Direct Connect Architecture 
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rint a felügyeleti programokat a 
gyártók nem, vagy csak korláto- 
zott funkcionalitással készítik el.) 
n Bármilyen, nem natív 64 bites (vagyis 32 
bites) szerverszoftver telepítése és üzemel 
tetése gyakorlatilag tilos és életveszélyes. 
A javasolt alternatíva ilyenkor, hogy a 64 
bites operációs rendszeren egy 32 bites 
operációs rendszerrel rendelkező virtuális 
gépet üzemeltessünk, amin már nyugod- 
tan futhat a 32 bites szerverünk (abban az 
esetben, ha a szerverszoftverünk virtuali 


zációja tamogatott). 


Jó tanácsok 

Ha otthonra vettünk számítógépet, és nem 
vagyunk CAD/CAM-mérnökök, véletlenül 
se tegyünk fel 64 bites kliens-operációsrend- 


szert még, hacsak nem vagyunk biztosak 
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Az AMD 64 bites Opteronjának doboza 


32 bitesnél egyelőre, és várjuk meg, míg lesz 
natív 64 bites verzió belőle. Ha van 64 bites 
változat, és szeretnénk kihasználni az elő- 
nyeit (több memóriára lesz szükségünk, illet 
ve szeretnénk kapni némi teljesítménytöbb- 
letet), akkor tegyük fel a 64 bites operációs 
rendszert (a fentebbi szempontok figyelem- 
bevételével). TIermészetesen jó, ha a telepí- 
tés előtt tájékozódunk arról, hogy a jelenlegi 
teljesítményproblémákat valóban a 32 bites 
platform korlátjai jelentik-e? Mert, ha nem 
a platform korlátait értük el, hanem egyéb 
szoftver- vagy lekérdezés-optimalizációs prob- 
lémával állunk szemben, abban az esetben 
tényleg ne várjuk azt, hogy a 64 bites plat 
form megoldja a problémánkat. Ha csak 64 


L — be 
S 


bites verzió létezik a szerverszoftverből, ak 
kor kénytelenek vagyunk feltenni alá a 64 
bites operációs rendszert is - azonban ez már 


egyáltalán nem rossz kombináció. 


A választék 

Az operációs rendszerek közül a következők 

érhetők el 64 bites változatban: 

n Windows XP (x64) 

n Windows Vista (x64) 

n Windows Server 2003 (R2 - Itanium és 
x64) 

Lássuk, milyen fontosabb Microsoft alkal 
mazásokból áll rendelkezésünkre 32 bites és 
natív 64 bites változat egyaránt. Ezeket már 
nyugodt szívvel feltehetjük 64 bites operá- 
ciós rendszerre is: 

Office 2007 (kliens- és szerveralkalmazá- 

sok is); 

n SOL Server 2005, Bizlalk Server 2006; 

a Virtual Server 2005 R2 (fut natív 64 bi 
ten, de csak 32 bites virtuális gépet tud 


futtatni); 

a a későbbi System Center termékek (tavasz- 
szal érkeznek); 
n a ,Longhorn" Server (2007 vége). 

Ehhez kapcsolódik még a Windows Server 
2003-ban (az R2 funkcióival egyetemben) ta- 
lálható valamennyi képesség, ezek mind elér- 
hetők natív 64 biten is, beleértve az Internet 
Information Servert, a .Net keretrendszer 
2.0-s változatát is, vagy akár az Active Direc- 
toryt. A .Net és az IIS képes profitálni a 64 
bit előnyeiből, és így a rajta futtatott alkal 
mazások is. 

A következő szerverekből például nem ér- 
hető el jelenleg natív 64 bites változat, ezeket 
most még ne akarjuk 64 bites operációs rend- 
szeren futtatni: 

n ISA Server 2004/2006; 


x Microsoft Operations Manager 2005, 


Syvetenns Management Server 2003; 
a Exchange Server 2003. 
Ezek a szoftverek pedig már csak natív 64 
bites változatban érkeznek: 
a Exchange Server 2007; 
n SOL Server vNext (Katmai); 
a Small Business Server vNext (Cougar); 


n , Longhorn" Server R2. 


Magyarázat 
az Exchange Server 2007-hez 
Az Exchange Server 2007 - mint az első, ki- 


zárólag natív 64 biten támogatott Microsoft 
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szerveralkalmazás - némi külön magyará- 
zatra szorul. Az első érdekesség vele kapcso- 
latban, hogy létezik belőle 32 bites változat 
- csak nem támogatott és kereskedelmi for- 
galomban sem kapható. De akkor mégis 
miért van 32 bites változat? 

Ennek több oka is van: egyrészt jelen- 
leg nincs olyan virtualizációs technológiánk, 
ami képes 64 bites operációs rendszerű vir 
tuális gépet futtatni. A Virtual Server 2005 
R2 létezik ugyan natív 64 bites verzióban, de 
ettől még az sem tud 64 bites virtuális gépet 
emulálni nekünk. Márpedig azok, akik ki 
szeretnék próbálni az Exchange Server 2007- 
et - vagy éppen a korábbi bétateszterek -, sze- 
retnek virtuális környezetben dolgozni vele, 
hogy felfedezhessék a rendszer képességeit. 
Éppen ezért amikor megjelent az Exchange 
Server 2007 beta 1, már volt is belőle 32 
bites változat. Erre a problémára amúgy a 
Windows Virtualization ad majd megoldást, 
amint megjelenik a , Longhorn" Server után 
nem sokkal, ugyanis az már képes lesz futtat 
ni 64 bites virtuális gépeket is. 

Külön érdekesség, hogy a végleges Ex 
change Server 2007-ből is létezik 32 bites vál 





tozat, ami tesztelésre bármikor használható, 
csak éles környezetben nem lehet sem licen- 
celni, sem használni, valamint ebből követ 
kezően támogatást sem kapunk hozzá. De en- 
nek mégis mi az oka? Az, hogy az Exchange 
Server 2007 valóban lényegesen jobban tel 
jesít 64 bites környezetben, mint 32 biten, 
valamint a legtöbb nagy hasznát veszi a $ gi- 
gabájtnál több memóriának is - emiatt már 
a kezdetektől fogva erre fókuszáltak a fejlesz- 


tők és a tesztelők a Microsoftnál. 


Mit hoz a jövő? 

Minden Microsoftszerverszottverből lesz 64 
bites változat a közeli jövőben, sőt 2008-tól 
már kizárólag 64 bites szerverszoftverek je- 
lennek meg. 

Az első, kizárólag 64 bites változatban elér 
hető szerverszoftver a decemberben elkészült 
Exchange Server 2007. A Windows Vista és 
a , Longhorn" Server pedig nem más, mint a 
Microsoft két utolsó, 32 bitesen is elérhető 
operációs rendszere. 

A készülő ,Longhorn" Serverre épü- 
lő új Small Business Server, valamint a 


, Longhorn" Server R2-es változata viszont 
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már csak 64 biten lesz elérhető. Várhatóan 
az SOL Server soron következő változata is 
csak 64 bites verzióban érkezik és a követke- 
ző [SA Server is. 

Szerencsére jól látható, hogy a Microsoft 
azokból a szoftverekből, amelyeknél nem 
mindenki számára egyértelmű a 64 bit hasz- 
na, elkészíti a 32 bites változatot is. Azoknál 
a szoftvereknél azonban, amelyek egyértel- 
műen és lényegesen gyorsabbak 64 biten, 
a jövőben csak 64 bites verziókat szállít és 
támogat majd (ilyen például az Exchange 
Server 2007). 

Ez a hozzáállás azonban csak időszakos, 
mint minden generációváltáskor, és csak ad- 
dig tart, amíg a legtöbben végre átállnak 64 
bitre. A trend megállíthatatlan, ugyanis a 
szerverszoftverek adatbázisainak mérete és 
teljesítményigénye már egyre több helyen 
igényli ténylegesen a 64 bit adta előnyöket, 
valamint végre a drivergyártók és a kisebb 
szoftverfejlesztők is elkezdik komolyan venni 
a 64 bitre történő átállás és fejlesztés szüksé- 
gességét. 

Budai Péter 
(i-pbudai(oOmicrosoft.com) Microsoft Magyarország 
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TÜZETES 


LLENŐRZÉSEK 


Spam- és vírusszűrés az Exchange Server 


2007-ben. 


Microsoft utóbbi 4-5 évének történései nagyrészt a platformok és az alkalmazások biz- 


tonságának jegyében teltek. Ez világosan érezhető a 2006-os év triászán, azaz a Vista, 


az Office 2007 és az Exchange Server 2007 (a továbbiakban egyszerűen Exchange) 


együttesén is. A törekvéssel már a telepítéskor találkozunk, hiszen ezek a rendszerek és köz- 


tük is főként az Exchange - a biztonsági alrendszereikkel együtt 
- olyan technológiákkal települnek, amelyek a legtöbb felhaszná- 
ló és szervezet védelmi igényeit kapásból kielégítik. 

Írásunkban az Exchange-nek azokat a biztonsági vonatkozásait 
tekintjük át, amelyek az internetes kellemetlenségek és fenyege- 
tések, azaz a levélszemét és a kártevők elleni közvetlen védelmet 


szolgálják. 


Réteges védelem 

A kéretlenlevélt és kártevőküldők számos technikát használnak 
küldeményeik célba juttatására, ezért elég nehéz lenne egyetlen 
olyan eszközt megjelölni, amelyet tökéletes védelmi megoldásnak 
lehetne kikiáltani. Az Exchange olyan, a korábbi változatok ké- 
pességeire épülő védelmet használ, amelyben a biztonsági techno- 
lógiák többszintű védelmet biztosítanak, és amelyben a spam- és a 
vírusvédelem szorosan kapcsolódik egymáshoz. Ennek közismert 
oka: a rosszindulatú kódok terjedése közvetlenül összefügg a le- 
vélszeméttel, és ha utóbbit sikerül eliminálni, akkor az előbbi ve- 
szélye is megszűnik, de legalábbis csökken. 

Minél korábban, azaz a szervezet hálózatba lépési pontjához mi 
nél közelebb történik a szűrés, annál kisebb az infrastruktúra belső 
erőforrásainak a sávszélesség- és erőforrás-terhelése, ezért a spam- 
és vírusvédelmi funkciók alapbeállítás szerint az Edge Iransport 
szerepkörbe vannak beágyazva. Ettől függetlenül az alább ismerte- 
tett folyamatokat a Hub Iransport szerepkörön is engedélyezhet 
jük kézi konfigurálással (PowerShellel kell elvégezni ezt a műve- 
letet, az installAntispamAgents.msh scripttel), de általában érde- 
mesebb ezeket a képességeket az Edge-en megvalósítani, elvégre az 


teljesen elszeparáltan helyezkedik el még a címtárunktól is. 


Kapcsolatszűrés 


Szűrés feladó szerint 


Címzett szerinti szűrés 





Szűrés küldésazonosító 
alapján 


Tartalomszűrés 


Csatolmányszűrés 


Vírusellenőrzés 


Spamszűrés az 
Outlookban 





1. ábra. A spam- és vírusszűrés 
egymásra épülő rendszere az 
Exchange 2007 rendszerben 


A réteges védelem az Exchange esetében azt jelenti, hogy a beérkező küldeményeket vizs- 


gáló technológiák meghatározott sorrendben végzik a dolgukat; minden szűrőmódszer az üze- 


netek meghatározott tulajdonságait vizsgálja az I. ábrán bemutatott struktúrának megfelelő 


Ki 


mliadi x 


módon. A továbbiakban a séma különböző 


részfeladatait tekintjük át. 


Kapcsolatszűrés 

Az Exchange-ben a kapcsolatszűrő a 2. ábrán 
bemutatott módon vizsgálja az SMI P-szerver 
által kezdeményezett kapcsolatot a követke- 
ző feltételek szerint: 

1. A szűrőágens megvizsgálja, hogy az 
SMIP:szerver címe rajta van-e az adminiszt 
rátorok által definiált IP-engedélyezési lis- 
tán. Ha igen, akkor az üzenet továbbmegy a 
feladószűrőhöz. 

2. Ha ai SMIP-szerver címe rajta van a til 
tandó IP-címek listáján, akkor az üzenetnek 
elutasítás a sorsa, és nincs további szűrés. 

3. A kapcsolatszűrő megnézi, hogy külső 
szolgáltatótól származó engedélyezési listán 
szerepel-e a küldő IP-címe. Ha igen, akkor az 
üzenet továbbmegy a feladószűrőhöz. 

4. Ha a küldő címe szerepel az ugyancsak 
külső szolgáltatótól származó RBL-en (va- 
lós idejű blokkolólista), akkor a küldemény 
blokkolódik, és nincs további szűrés. 

Nem mellékesen a küldő IP-címét a rend- 
szer két helyen is figyeli: az egyik forrás ma- 
ga az engedélyezett kapcsolat, a másik pedig 
a levelek fejléce, de ezt már a feladó szerinti 


szűrést végző egység figyeli. 


Feladó 


A kapcsolatszűrés után a 3. ábra szerint tör- 
ténik a feladó e-maibkcímének vizsgálata. Ez 
egyszerűen annak ellenőrzését jelenti, hogy 
a levél fejlécében szereplő küldési cím sze- 
repele az adminisztrátorok által karbantar- 
tott blokkolandók listáján. Ha igen, akkor a 
küldemény protokollszinten blokkolódik, és 
nincs további szűrés. 

Ha a feladó a felhasználók Outlookjaiban 
szerepel is a biztonságos küldők listáján, de a 
feladó szerinti szűrés során ,könnyűnek ta- 


láltatott", akkor természetesen blokkolódik. 


Címzett szerinti szűrés 

A 4. ábra címzett szerinti szűrést ábrázoló sé- 
májából nem tűnik ki, de ezt a részfeladatot 
megelőzi egy ismételt kapcsolatszűrés. 

A címzett szerint szűrő ágens azt vizsgálja, 
hogy a küldemény címzettje szerepel-e a blok- 
kolandó fogadók listáján. Pozitív esetben a 
kézbesítés leáll, és nincs további szűrés sem. 
Ugyanez történik, ha a rendszerben nem léte- 


zik a címzett e-mailtcíme. Ha a levélnek több 
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címzettje is van, akkor a küldemény csak ak- 
kor blokkolódik, ha egyik cím sem létezik, 
vagy az összes fogadó rajta van a blokkolandók 


lajstromán. Egyébként csak a blokkoltak felé 


nél - komoly szempont az elutasított külde- 
mények mennyisége. 
A , Sender ID" vagy , küldőazonosító" ke- 


retrendszerrel az 5. ábrán bemutatott mó- 








Feladó szerinti szűrés 





Az SMTP-szerver SMTP-munkafolyamatot kezdeményez 








2. ábra. A kapcsolatszűrés 


áll le a továbbítás olyan módon, hogy a szűrő- 
ágens ezeket a fogadókat törli a fejlécből. 
Itt jegyezzük meg, hogy az elutasított kül 


deményekről a feladók rendszerei értesítést 


don annak a vizsgálata megy végbe, hogy a 
küldemények olyan internetes doménről ér- 


keznek-e, amelynek IP-címtulajdonságaihoz 


illeszkedik a levél küldőjének az IP-címe. A 
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Címzett szerint szűrés 













A feladó címe rajta van 
a feladó szerint 
NEM ! szűrő ágens listáján? 


(. ! Üzenet blokkolása: 
nincs további szűrés 








3. ábra. Feladó szerinti szűrés 


kapnak. Ugyancsak itt fontos szólni a , küldő 
reputációjáról", amely egy diszkrét számmal 
jelölt paraméter, és a kiszámításánál - azaz 


a küldő megbízhatóságának számszerűsítésé- 


Sender ID nem más, mint a küldő nyilvános 
DNS-kiszolgálójának SPE-bejegyzése (Sender 
Policy Framework, körülbelül: ,küldő sza- 


bályrendszer"). Az SPF tartalmazza azokat az 





Feladó szerinti szűrés 


Sender ID szerinti szűrés 














4. ábra. Címzett szerinti szűrés 
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IP-címeket, amelyek az adott tartományból 
leveleket jogosultak feladni. Ha a megcímzett 
rendszer lekérdezi az SPF-bejegyzést, a vissza- 
térő ,oké" jelzést úgy kell értelmezni, hogy 
a kérdéses küldemény nagy valószínűséggel 
legitim feladótól származik. Természetesen 
az Exchange a speciális esetekre - például 
DNS-problémákra - is felkészíthető. 

A küldőazonosító ágens először egy spe- 
ciális, az RFC 4407-es szabványban leírt al 
goritmussal meghatározza a feladó SMT P-cí- 
mét, ami mondjuk így néz ki: ,valakiopelda. 
hu". Ezután végrehajt a cím doménszegmen- 
sére - ,pelda.hu" - egy DNS-lekérdezést 
(lookup). Ha az adott internetes tartomány 
közzétett egy SPE-bejegyzést, akkor az ágens 


erről kap egy pozitív eredményt, amit , rábé- 


lyegez" a küldeményre. 


Peremszinkron 





Az Exchange védelmi képességei olyan transzport- 
szintű ágenseket (is) alkalmazhatnak, amelyek az 
Exchange Management Shell segítségével felügyel- 
hetők és szkriptelhetők. 

A felügyeletet segíti még az EdgeSync, amely szer- 
vesen kapcsolódik a transzportágensekhez, pon- 
tosabban a beállításaikhoz és azok érvényesítésé- 
hez: a szolgáltatással könnyen szinkronizálhatók 
az ágensek konfigurációs információi azokon a ki- 
szolgálókon, amelyeken az Edge Transport szerver 
szerepkört telepítették. 

Az EdgeSync olyan folyamatok gyűjteménye, ame- 
lyek a címzett- és beállítási adatokat replikálják 
egyirányú üzemmódban az Active Directory felől az 
ETS alkalmazás módú (ADAM) címtárai felé. Az Edge- 
Sync csak azokat az adatokat másolja át, amelyek 
az ETS spamszűrő és üzenetbiztonsági konfigurációs 
feladataihoz kellenek, illetve a küldemények kifelé 
— az internet felé — irányuló zavartalan forgalmazá- 
sához szükségesek egy vagy több ETS-en keresztül. 
Az EdgeSync szolgáltatás időzített frissítései gon- 
doskodnak róla, hogy az ADAM beállításai a teljes 
organizációban frissítve legyenek. 





Ha az adott domén nem tett közzé SPF-be- 
jegyzést, akkor is lebélyegzi, de egy , semmi" 
pecséttel. 

A küldemények további lehetséges sorsa: 
an Ha a küldőazonosító elutasításra van beál- 

lítva, akkor a levél blokkolódik, és erről a 

küldő SMIP:szervere is értesül. 


a Ha a beállított válaszlépés a törlés, akkor 


Ki 
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az Exchange törli a levelet és nem infor- 
málja a küldőt - pontosabban küld neki 
egy hamis ,oké" jelzést, és szívfájdalom 
nélkül töröl, hogy a küldő szerver ne baj- 
lódjon az ismételt küldésekkel. 


ző üzeneteket valószínűségi paraméterekkel 
látja el annak megfelelően, hogy a vizsgálat 
alapján mennyire látszanak elfogadható vagy 
káros tartalmat hordozó küldeménynek, il 


letve spamnek. 













Címzett szerint szűrés 
ke ] 
EE I IGEN NEM CT Üzenet 
Feladó DNS lekérdezése Az üzenet blokkolt Engedélyezett a küldőazonosítás — blokkolása; 
£  SPF bejegyzésre tartományból IGENT sikertelensége esetén nincs további 
5 engedélyezett? NEMI jön? a továbbítás? szűrés 
E —— ]) Az üzenetet , Sikertelen küldő- 
s azonosítás" jelöléssel kell ellátni 
4 TETT sszapot ? kié dme rar var?! Szírés a küldöszonosító szerti szírési 
IP-címének a vizsgálata a biokkolandók beállítások alapján, majd szűrés vége 
engedélyezett? NEMI listáján? 
Tartalomszűrés 














5. ábra. Szűrés küldőazonosító szerint 


an Ha a küldőazonosító szerint szűrő ágens 
továbbengedésre van programozva, akkor 
az ágens a vizsgálat eredményéről készült 
pecséttel lebélyegzi a küldeményt, és an- 
nak tovább folyik a vizsgálata. Ez az ered- 


mény a továbbiakban a küldő megbízha- 


A tartalomszűrés fontos előszobája az ábra 
öt feltételének ellenőrzése. Ezek bármelyiké- 
nek pozitivitása esetén a levél egyenesen a 
víruskeresőhöz kerül. 

Az elemzéshez az EIMF összesíti a kapcso- 


lat, küldő-, fogadó-, reputációs-, Sender ID 





Sender ID szerinti szűrés 


Csatolmányszúrés 











Vírusszűrés 





6. ábra. Tartalomszűrés 


tóságának és a következő szakaszban rész- 
letezett SCL-értéknek a kiszámításában is 


fontos faktor lesz. 


Tartalomszűrés 

A 6. ábra szerint működő folyamat alapja a 
SmartScreen ,önképző" eljárással működő 
Exchange Intelligent Message Filter (EIMF) 


technológia. Ez a szűrőmódszer a beérke- 
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ellenőrző adatokat is - sőt, figyelembe ve- 
szi az Outlook 2007 bélyeghitelesítési infor- 
mációit -, és ezek alapján határozza meg az 
adott üzenet megbízhatósági szintjét (spam 
confidence level, SCI). Az SCL különböző 
szintjeihez további akciók rendelhetők: 

a kézbesítés Outlook-postafiókba vagy a fel 

használó levélszemétgyűjtőjébe; 


a küldés levélszemétkaranténba; 


Sai NE 


a nincs küldés; 
m az üzenetet fogadja a szerver, de a továbbí- 
tás helyett nemes egyszerűséggel törli. 

Az említett , spam-karantén" egy ideigle- 
nes szervezeti tár a levélszemétként azonosí- 
tott küldeményeknek. A funkció a tartalom- 
szűrés szerves részeként van implementálva. 
Az ide kerülő levelek természetesen nem 
jutnak el a felhasználókhoz, de az adminiszt 
rátorok hozzájuk férnek, és törölhetik őket, 
illetve a tévesen spamként azonosított - fals 
pozitív - küldeményeket továbbíthatják a fel 
használókhoz. 

Maga a tulajdonság kétlépcsős mechaniz- 
mussal működik. Az első lépcsőben a rend- 
szergazdák kapcsolódnak a periméteren el 
helyezkedő spam-karanténhoz. Az elérés egy- 
szerűen az Outlookkal történik. Az üzenete- 
ket vizsgálat után egyszerűbb esetben tovább 
lehet küldeni a címzetthez, vagy ki lehet tö- 
rölni. A második lépcső az adminisztrátorok 
által kérdésesnek minősített SCL-értékű, az- 
az , határesetküldemények" szintje. Ezek elő- 
ször a járulékos védelem okán szöveges for- 
mátumra konvertálódnak, majd a felhaszná- 
lói levélszemétfiókba továbbítódnak - hadd 
győzködjön velük ő maga, pontosabban a 


kliensprogramja. 


A csatolmányok ellenőrzése 

A 7. ábra szerinti csatolmányvizsgálat több 

szempont szerint - így például MIME-tar- 

talomtípus, fájlnév vagy kiterjesztés, méret 

- történhet. 

Az eredménytől és a beállításoktól függően 

a következők történhetnek az üzenettel: 

n Ha elutasításra van programozva az ágens, 
akkor sem a levél, sem a csatolmánya nem 
kézbesítődik, és a küldő kap egy DNS-hi- 
báról szóló értesítést, amely egyébként tet 
szés szerint alakítható. 

m A ,csendes törlésnél" is blokkolódik a kül 
demény, de a küldő rendszer nem kap ér- 
tesítést. 

a A , lehámozásnál" az e-mail a csatolmány- 
tól megfosztva továbbítódik úgy, hogy a 
csatolmány eltávolításáról szóló megjegy- 


zéssel egészül ki a szöveges tartalma. 


Többszintű vírusvédelem 

Az Exchange 8. ábra szerint működő vírus- 
védelméhez több újítás is kapcsolódik. A 
korábbi változatok víruskereső programozá- 


sára szolgáló felülete (VSAPD itt is megvan, 


Microsoft TechNet 
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de a Microsoft - szándékai szerint hatéko- 
nyabb és ugyancsak programozható - pásztá- 
zóeszközöket valósított meg transzportszin- 


ten is. Érdemes kiemelni, hogy a Microsoft 














Tartalomszúrés 
! A küldemény blokkolása, 
Csatolmány- és a feladó értesítése 
— 8 — vizsgálat vs! VAGY a kézbesítés megtagadásáról 
2, bekapcsolva? mentET 7BE A küldemény törlése; 
s A küldemény csatolmányának MIKES TÖK EGTTES 
2 típusa blokkolandó VAGY 
8 fájl vagy tartalom? Csatolmány eltávolítása 
a küldeményről 
Vírusszűrés 


Tartalmazza annak eredményét, és így kikü- 
szöböli a többszörös - és felesleges - vírus- 
ellenőrzéseket, illetve jelzi, ha további kont 


rollra van szükség. 












7. ábra. Csatolmányok szűrése 


ForeFront vírusellenőrző megoldások képe- 
sek futni a Mailbox szerepkörű szervereken 
is, ott a mailboxok tartalmát vizsgálják idő- 
ről időre a VSAPLn keresztül. 

A ForeFront szoftverek és az Exchange 


2007 azonban most már sokkal inkább részé- 


Az Exchange transzportszintű ügynökei 
meglehetősen hasonlítanak a korábbi válto- 
zatok event sinkjeire. A transzportágensek 
segítségével külső fejlesztők is írhatnak olyan 
komponenseket, amelyekkel további, trük- 


kös kórokozók ellen védő megoldásokat le- 





Csatolmányszűrés 


Outlook levélszemét-szűrés 








Tartalomszűrés 








8. ábra. Kórokozók vizsgálata 


vé válik a tényleges levélforgalom vírusszűré- 
sének is. Ennek letéteményesei a Magazin 
más cikkében tárgyalt transzportágensek, 
melyek az alkalmazások eseményeihez beállí- 
tott válaszlépéseket foganatosítanak. 


Az Exchange-ben megjelent az , antivírus- 


het implementálni a rendszerbe, vagy akár 
a teljes levélforgalmat is lehet ezekkel vizs- 
gálni és manipulálni. Ezeknek a használatát 
az Exchange stabil és az évek során meglehe- 
tősen élesre - és megbízhatóra - köszörült 


MIME-kezelő motorja segíti. 





Vírusszűrés 


Outlook 
levélszemét-szűrés 








i 8 
: Az Outlook spamszűróője BB ETL ai 
i ? 
1 Kdrekapésotats küszöbértéket? 


Üzenet továbbítása a levélszemét mappába 


Üzenet normál kézbesítése 








9. ábra. Az Outlook levélszemét-kezelése 


pecsét" is. Ez egy olyan, az üzenetekre ke- 
rülő jelzés, amely a szervezeten belül iga- 


zolja a már lezajlott kórokozó-ellenőrzést. 


naaa AL AL HEK S 


Itt utalunk még az előző számban tárgyalt 
Forefront Security for Exchange Serverre, 


amely a beépített vírusvédelem kiegészítője- 


ETI 


ként további robusztus kártevővédelmet kí- 
nál az Exchange-rendszerekhez - ez is itt kap- 


csolódik be ugyanis a folyamatba. 


Végállomás 
Ezen a szinten a küldemények a szervezet le- 
velezőrendszerében a rendeltetési helyükhöz 
érnek. Itt már csak a címzettek postafiókjai- 
ban van hátra némi munka. 

Az Exchange teljes rendszerének szerves 


részét képező Outlookkliensek az Exchange 


ATA jan toyzáel tte] 


Szignatúrák. Az Exchange járulékos lehetőségei 

gondoskodnak a spamszűrők aktualizálásáról: 

m az Exchange Standard Anti-spam Filter Update 
kéthetente, 

m a Forefront Security for Exchange 2007 24 órán- 
ként frissít. 

EdgeSync. A címzett szerinti szűrésnél a lapunk más 

írásában tárgyalt EdgeSync gondoskodik a címzett 

szerint szűrő ágenseknek szóló adatok ADAM-szin- 

tű aktualizálásáról az Edge Transport Server(ek)en. 

A transzportszintű ügynökprogramok egyszerűen le 

tudják kérdezni, hogy a beérkező küldeménynek 





van-e valós vagy legális címzettje a szervezetben. 
Reputáció. A küldő reputációjának, azaz a feladó 
elfogadhatóságának az adatai nem kőbe vésett 
paraméterek, hanem több információ — SMTP-mun- 
kafolyamatok, tartalomszűrő, Sender ID-ellenőrzés 
és a feladó általános viselkedésére és , előéletére" 
jellemző profilok elemzéséből származnak. A reputá- 
ciós kalkulus ezekből dinamikusan számítja ki, hogy 
.Tekete-" vagy , fehérlistára" tegye-e a feladót, és 
blokkolja-e a küldeményeit. 

IP-reputáció. Ez a vadonatúj technológia, a küldő 
IP-címe elfogadhatóságának vagy megbízhatósá- 
gának elemzését és a kapott számszerű érték hasz- 
nálatát jelenti. Ilyen jelenleg csak az Exchange-ben 
létezik, és a többi valós idejű blokkolólehetőséghez 
hasonlóan ki-be kapcsolható. 

Nyelvfüggetlenség. A spamvédelem további fontos 
jellemzője, hogy az alkalmazott biztonsági techno- 
lógiák nagy része nyelvfüggetlen. 





minősítésének - elsősorban az SCL-érték- 

nek - a figyelembevételével dönti el, hogy 

értékes küldeményként a postaládába vagy 

spamkérnt a levélszemétmappába sorolja be a 
küldeményeket. 

Kelemen László 

(kelemenohungary.com) 


Ke 
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POWERSHELL-SCRIPTEK 


A GYAKORLAIBAN 


Az előző részben megismerkedtünk a ,fejjel a falnak" módszer 


hatékonyságával, és bizony elég jelentős haladást értünk el 


a PowerShell-rendszer megismerésében. Ebben a részben picit 


behatóbban elemezzük a CommandlLeteket, valamint megismerkedünk 


az objektumok feldolgozásának kilenc fontos parancsával. 


ferencián a PowerShell atyjának, Jeffrey Snovernek az előadásán, aki azt mondta: a 


A z előző cikk óta volt szerencsém részt venni Barcelonában, a Tech" Ed: IT Forum kon- 


PowerShellfelhasználónak négy barátja van: 


1, HELG 

Zs ALLAS 

3. GEI-MEMBER 
4. GEIPSDRIVE 


A rendszer felfedezése 


Mindez magyarul azt jelenti, hogy erre a cikkre sincs semmi szükség, minden benne van a 


helpben. Csak hát angolul. Jeffreynek viszont mégiscsak teljesen igaza van, mert ha valaki egy 


adott parancs részleteire kíváncsi, akkora helpet kap, hogy arról kódul. Külön ki kell emelni 


az -example parancsot, amivel minimum három kiváló példát kapunk az adott CmdLet hasz- 


nálatára. Például ezt találjuk a HELP DIR -EXAMPLE outputjában: 


get-childitem registry::hklmisoftware 


Lámdám, a DIR paranccsal (ami mellesleg cask egy alias a getchilditem CmdLetre) ki lehet 


listázni a registry tartalmát! Innentől beindul a fantáziánk: és még merre csatangolhatunk? 


2 Windows PowerShell with PowerGadgets 


PS C:N2 get-psdrive 


A rendszergazda negyedik ba- 
rátja, a GELPSDRIVE (magya- 


rul: kérem a PowerShellmeghaj- 


tókat!) szerint még jó pár helyre 
vándorolhatunk a sima CD és 


DIR parancsokkal. 


Változók 


Itt vannak például a környeze- 


ti változók (ENV: ). Milyen jó 
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ő TR Kat -s 


Alias 

FileSyustem 

Certificate 

FileSyustem 

Enyironment 

Function 

Registry HKEY CURRENT USER 
Registry HKEY LOCAL MACHINE 
Uariable 





A PowerShell ,meghajtókkal" bejárhatjuk az óperenciás rendszert 





is lenne kihalászni ebből a listából mond- 
juk a számítógép nevét! Így a script pon- 
tosan tudná, hogy hol fut. Vagy esetleg a 
LOGONSERVER értékét, mert akkor pon- 
tosan tudhatnánk, hogy melyik tartomány- 


vezérlő jelentkeztetett be minket. Hát lássuk! 


dir env: ] where ($ . .Name -eg , COMPUTERNAME "3 


Magyarázat: a dir env: (valójában getchild- 
item env:) előállítja az összes környezeti változó 
értékétegy .netobjektumkupacban (collection). 
Ezt a pipe (függőleges vonal, ] ) karakter segít 
ségével , belecsövezzük" egy lekérdezésbe, ame- 
lyik csak azokat a sorokat engedi át, ahol az ak- 
tuális objektum neve , COMPUTERNAME". 
Így egyetlen érték marad, pontosan az, ame- 
lyikre vadászunk. A PowerShell mindösszesen 
kilenc objektumkezelő CmdLetet tartalmaz. 


Ismerkedjünk meg velük! 


Objektumkezelés 

A kilenc parancs mindegyike valamilyen ap- 
ró műtétet hajt végre az objektumkupacon. 
Ezek közül jó pár az SOL-nyelv elemeire , ha- 
jaz" (SELECT " FROM TÁBLA), vagyis az 
objektumhalmazt horizontálisan (where-ob- 
ject) vagy vertikálisan (selectobject) ritkítja. 


A teljes készlet a következő (HELP OBJEC1): 


Microsoft TechNet 
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ForEachObject, Where-Object, Compare- 
Object, Measure-Object, Iee-Object, New- 
Object, SelectObject, Group-Object és Sort 
Object. A help ebben a sorrendben adagolja 
őket, mi inkább fontossági sorrendben fog- 


lalkozzunk velük! 


ForEach-Object (ALIAS: foreach) 


Az objektumkupac elemenkénti feldolgozá- 
sára való (kurzor). Végigszalad az összes ele- 
men, és az utasítászárójelben () megadott fel 
adatot elvégzi rajtuk. 

Ha ez emailkcímek listája, akkor például 
minden címzettnek egyedi levelet küldhe- 
tünk a segítségével. Az előző cikkben (egyéb- 
ként téves algoritmussal) körök kerületét szá- 
moltuk ki vele, ezért erre most külön példát 


nem érdemes hozni. 


Select-Object (ALIAS: select) 


Amikor valaki lekérdez néhány objektumot 
(például: DIR), talán nem is tudja, hogy 
mennyi, de mennyi adattal rendelkezik az 
adott objektum! A képernyőkép (output) csa- 
lóka: van néhány olyan tulajdonság, amelyik 
megjelenik, a többi rejtve, settenkedve nyo- 
makodik át az objektumfeldolgozási csövön. 
Tehát egy sima parancs a , SELECI "" bru- 
talitásának felel meg: ide nekem az oroszlánt 
is! Ez még egy-két objektumnál nem jelent 
gondot, de pár tízezernél már igen. Van ek 
kora objektumlista? Persze, például az ese- 
ménynapló! Csak hasonlítsuk össze az alábbi 


két parancs kimenetét: 


dir ] get-member 


és 


dir ] select name ] get-member 


A getmember - mint a bevezetőben lát 
tuk - a rendszergazda egyik legjobb barátja. 
Arra való, hogy megmutassa, egy adott ob- 
jektum mit tud, milyen adatokkal és metó- 
dusokkal rendelkezik. 

Nos, a sima DIR legalább huszonharminc 
tulajdonságot tárol minden fájlról és könyv- 
tárról. A második, szűrt változat viszont csak 
egyet. Hát szűrjünk! 

(Egészen pontosan 28 property lesz a szűrés- 
mentes lista minden elemén. Kis előretekintés, 


így számoltuk meg: dir ] getmember ] where 


DECEMBER-JANUÁR 





2 Windows PowerShell with PowerGadgets k , 


PS C:N2 compare-object (get-content boot.ini) (get-content autoexec.bat?) 


InputObject 


(decho off 
loader] 


GTA s 
timeout -3A 
default-multi(4ddisk(Adrdisk(Hdparti. 
[operating syustems] 
multiCAddisklAdrdiskl,HAdpartitionki19xX... 


Fájlok tartalmának összehasonlítása compare-objecttel 


($. membertype -eg , property") I measure-ob- 
ject property membertype. Türelem, még két 


oldal, és ez az egész parancs érthető lesz...) 


Where-Object (ALIAS: where) 


Sorok ritkítása. Egy getprocess vagy egy 
geteventlog az összes processzt, illetve az 
eseménynapló mind a százezer elemét lazán 
az objektumkupacba tolja, csak győzzük fel 
dolgozni. A where-object abban segít, hogy 
ne az menjen át a következő feldolgozóegy- 
ségbe, ami a csövön (pipe) kifér, hanem csak 
azok az objektumok, amelyek valóban feldol 
gozásra kerülnek. Például a 20 megabájtnál 
nagyobb memória-munkaterületet (working 


set) használó folyamatok: 


get-process ] where ($... .WorkingSet -gt 20MB3 


Ez ennyi, nem több. A Where utasítászáró- 
jelében lévő feltétel magyarázata: a dollár spe- 
ciális karakter, amellyel változókat jelölünk 
(mint ahogy például SOL-ben a kukaccal: 2 
valtozo). A dolláraláhúzás pedig egy speciá- 
lis változó, az éppen aktuális, feldolgozás alatt 
álló objektumot jelöli. A -gt pedig nem Gál 
Tamás monogramja (bár az is lehetne), hanem 
Greater Than, azaz nagyobb, mint. Miért 
nem úgy jelölik, ahogy , normális" nyelvekben 
szokás C-)? Azért, mert egy parancssorban ál 
lunk, ahol a kacsacsőrök (X és ?) teljesen mást, 
nevezetesen átirányítást jelentenek. Ez a fur 
csa , műveleti jel" a gordiuszi csomó átvágásá- 


val egyenértékű professszionális megoldás. 


Compare-Object 

Tárgyak és tárgylisták összehasonlítása. A 
PowerShell objektumorientált megközelítése 
miatt ez a parancs bármilyen objektumtípus 
összehasonlítására alkalmas: fájlok tartalmá- 
ra éppúgy, mint processzlistákra és registry- 
kulcsokra. Vessük össze például a boot.ini 
és az autoexec.bat tartalmát! Az alábbi példa 


kilistázza a két fájl közötti eltérést. 


Sidelndicator 


.. IL. AAL. MANI I E 


talalat 





Az eredmény önmagáért beszél, bal olda- 
lon látjuk az eltérő sorokat, jobbra pedig a 
kis nyilacska azt jelzi, hogy ez a bal vagy a 
jobb oldalon megadott fájlban van-e. Az 2 
echo off például a jobb oldaliban, tehát az 
autoexec.batban van. 

Érdekes elemzésre adhat lehetőséget, ha a 
compare-objectet előtte-utána üzemmódban 
használjuk. Egy hosszabb folyamat előtt is 
készítünk egy pillanatfelvételt a rendszer- 
ről (például processzlista, könyvtárlista stb.), 
meg utána is, a compare-object pedig kimu- 
tatja a változást. 

Ehhez a listatartalmakat változóba kell 
gyömöszölni, ami nem bonyolult dolog: kita- 
lálunk egy változónevet (dollárral az elején), 


és elkezdjük használni. Íme: 


$elotte— get-process 


Most jön egy hosszabb folyamat... 


$utana— get-process 
compare-obejct $elotte $utana 


Ez már gyakorlatilag script, hisz egynél 
több sorból áll. Mentsük el .PS1 kiterjesztés- 
sel, és valóban PS Scriptet kapunk. 


Measure-Object 

Ez a parancs összegzéseket végez az objektu- 
mok általunk megadott propertyjein. Ha szö- 
vegfájlra engedjük rá, megszámolja a szavakat, 
sorokat stb. Ha objektumkupacra, akkor pe- 
dig bármit megszámol, összegez, átlagol stb. 


Nézzünk először példát a szövegfájlkezelésre: 


get-content boot.ini ] measure-object -line —word 


A fenti parancs összeszámolja a boot.ini 
sorait és szavait. Most számoljuk meg, meny- 


nyi helyet foglalnak a merevlemezen a PPT-k: 
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dir -r -filter ".ppt.]  measure-object -property Length 
—sum 


Látható, a fájlok darabszámát önszorga- 
lomból megadta (count), az összegzésen felül 
pedig minimum-, maximum: és átlagszámí- 


tásra képes. 


Ez a parancs a csővezeték megcsapolására való. 
Amikor ,összecsövezünk" egy pár parancsot 
(régi példa: DIR ] SORT I MORE), az adatok 
csak a cső végén pottyannak ki. A DOS alkal 
mazásakor menet közben nem fértünk hozzá- 
juk, és ennek megfelelően nem tudtunk pél 


dául részeredményeket fájlba menteni. 







2 Windows PowerShell with PowerGadgets 


PS CN get-eventlog application : group 
perty count -desc 


Count Name 


4796 .NET Runtime Optinmizat... 
2172 MSSOLSERUER 


1373 MSSOLSSOLEXPRESS 
197 LoadPerf 
192 Msilnstaller 
133 1 
84 SOLISService 


A legszószátyárabb alkalmazás díját a .net runtime kapja 








PS G-VX2 dir -v -filter x.nnt j 


Count 22 
Áverage 
MATT 


rak ig 


Property 


Length 
Számoljuk ki, mennyit esznek a PPT-k! 
A tee-object megoldja ezt a gondot. Csak 


bele kell tenni a csőbe, és , ereszt", mégpedig 


fájlba vagy változóba. 


Objektumok csoportosítása és sorba rendezése 


valamelyik tulajdonságuk alapján. Például szá- 


——— ID] 


-property source -noelement :;: sort 0 a] a] 


tal I 2 


2" Windows PowerShell with PowerGadgets 


measure—-object 


"- property Length -—sum 





moljuk meg az application logban, hogy me- 
lyik alkalmazás hány bejegyzést tett, és ebből 
készítsünk egy sorba rendezett listát. Ehhez 
az eseménynapló bejegyzéseit a Source (for 
rás) tuljadonság alapján csoportosítjuk, majd a 
kész listát a Count alapján csökkenő sorrend- 
be tesszük. A -noelement arra szolgál, hogy 
dobálja el a konkrét eventlog-bejegyzéseket a 


feldolgozás során, mert arra nem lesz szükség. 


A következő cikk témája a COM, WMI és 

.NETobjektumok kezelése lesz, ezekhez a 
new-object parancsra lesz szükségünk. 

Fóti Marcell 

MCSE, MCDBA, MVP, MZ/X, MCT since 1995 

(marcellf-onetacademia. net) 
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Ismerje meg az üzleti biztonsági alkalmazások legújabb generációját, a betolakodók 
elleni küzdelem hatékony fegyverét, a microsoft.hu/biztonsag oldalon! 


: A Microsoft Forefront 
A Microsoft Forefronttal olyan üzleti biztonsági termékcsaládhoz 
juthat, amely a korábbiaknál átfogóbb, magasabb fokú védelmet 
biztosít, és tágabb szabályozási lehetőségeket kínál. Az ügyfélgépek, 
a kiszolgálói alkalmazások és a hálózat pereme számára egyaránt 


képes védelmet nyújtani: 


" Integrált 
Több területen fokozhatja a hálózata biztonsága feletti ellenőr- 
zést, mivel a termékcsalád biztonsági képességeinek integrálása 
a Microsoft kiszolgálói alkalmazásaival és a meglévő informatikai 
infrastruktúrával jóval nagyobb hatékonyságot nyújt. 





" Egyszerű 
A biztonsági termékek felügyeletének, telepítésének és hasz- 
nálatának egyszerűbbé tétele nagyban hozzájárul a szervezet 
biztonságának növeléséhez, és így On is egyszerűen bizonyo- 
sodhat meg arról, hogy folyamatosan a megfelelő védelemben 


[d-LYA-KIVTA 
Microsoft 


: Teljes körű szolgáltatás 
A Microsoft Forefront a teljes operációs rendszerre, minden alkalma- 
zásra és kiszolgálóra kiterjedő védelmet és hozzáférés-szabályozást 
biztosít az Ön információi számára, így azok biztonságban lehetnek 
a folyamatosan változó fenyegetésektől. 


0 2006 Microsoft Corporation. Minden jog fenntartva. A Microsoft, az Antigen és a Windows Server logó a 
Microsoft Corporation bejegyzett védjegye vagy védjegyei az Egyesült Államokban és/vagy más országokban. 
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KÉSZEN 
KAPOTT CRM 


Kinek és mire jó a Microsoft Dynamics CRM, 
és hogyan mérhető az üzleti teljesítmény az 
új, kiszolgáló alapú mutatószámrendszer és 
teljesítménymutató alkalmazás, a Business 
Scorecard Manager 2005 használatával? 


okan kérdezték tőlünk korábbi, Office témájú IechNeteseményeken, hogy milyen segít 

ség áll rendelkezésre saját CRM-alkalmazások készítésére az Office platformra. Létezik 

ugyan válasz erre is, de ismerve a fejlesztési projektek költségeit és kockázatait, elsőként 
érdemes megnézni, van-e már eleve olyan kész szoftver, ami megfelel igényeinknek. 

A Microsoft Dynamics termékcsaládja olyan informatikai megoldásokat foglal magában, 
amelyek a vállalatok mindennapi üzletmenetét, működését teszik hatékonyabbá. Segítségükkel 
az informatika és maga az informatikus is közvetlenül tud részt venni abban, hogy eredmé- 
nyesebbé tegye az érintett céget, nemcsak azáltal, hogy infrastruktúrát üzemeltet, hanem az- 
által is, hogy a döntéshozók és az értékesítők munkáját támogatja. 

A Dynamics szoftverek hasonlóképpen állíthatók üzembe, mint bármely másik Microsoft 
szerveralkalmazás vagy -megoldás. A legtöbb képességet a rendszerbevezetéssel foglalkozó 
informatikai szakemberek a megfelelő dokumentáció átböngészésével könnyen bekonfigu- 
rálhatják, hogy a szoftver tényleg az adott vállalat igényeinek feleljen meg. Ha mégis hiányzik 
valamilyen képesség, azt pedig könnyen hozzá lehet fejleszteni - bár ilyenkor érdemes lehet 
elsőként a rendelkezésre álló partnermegoldásokat megvizsgálni. 

A Dynamics CRM a termékcsalád legkisebb tagja, ezt kifejezetten kisebb vállalatok teljes- 
körű kiszolgálására vagy nagyobb vállalatok front office jellegű teendőinek ellátására találták 
ki. Az 5-10 felhasználóval dolgozó kisvállalatok ezt a terméket készen, dobozosan, előrekon- 
figuráltan érhetik el, a nagyobb vállalatoknak (akár 3000 felhaszálóval is) viszont érdemes 


testre szabniuk. 


Ugyfélinformáció: csak a fejekben? 

A CRM lényege egyébként, hogy az ügyfelekkel kapcsolatos elektronikus interakciókat és 
tranzakciókat is a mindennapi munka szerves részévé tegye, és olyan kényelemmel tudjunk 
ezekkel az új, elektronikus eszközökkel is bánni, mint ahogyan hagyományos, papír alapú le- 
veleinkkel és névjegyeinkkel tennénk. Emiatt már egyre több cég veszi igénybe ügyfélkapcso- 
latainak, ügyfélszolgálatának, illetve az ügyfelekkel kapcsolatban álló munkatársak munkájá- 
nak összehangolására. 


A cégek egy része már eddig is sokat tett annak érdekében, hogy ügyfeleit kellő módon ki 


 NUÁR 


(ENCAHET 


szolgálja, de még mindig nem tud eleget saját 
ügyfeleiről. Még ha meg is van a szükséges 
tudás a szervezeten belül, az sokszor csak a 
fejekben, szétszórtan található meg - vagyis 
az információ nem minden érdekelt számá- 
ra hozzáférhető módon áll rendelkezésre. A 
Microsoft Dynamics CRM-alkalmazásának 
az a feladata, hogy a technológiát hívja segít 


ségül e probléma orvosolására. 


Felhasználási lehetőségek, 
folyamatok 

Vállalati értékesítési folyamat automatizá- 
lása. Az érdeklődők, ügyfelek, kapcsolattar- 
tók nyilvántartása, megosztása és ripoltolha- 
tósága révén gyorsabb értékesítési ciklusok 
és jól mérhető értékesítési hálózat működte- 
tését teszi lehetővé. Lehetővé válik a poten- 
ciális lehetőségek felfedése, az értékesítési 
folyamatok testreszabása, valamint a hozzá- 
férés az ügyfelek vásárlási és kapcsolatfelvé- 
teli előzményeihez - bármely böngészőből, 
online vagy kapcsolat nélkül. 

Kampánymenedzsment és célcsoportok 
kezelése. Marketinglisták, kampányok, cél 
csoportok, vásárolt adatbázisok, de akár már 
a vállalat karácsonyi rendezvényére meghí- 
vottak listájának összeállítására is kiváló esz- 
köz. Kampányok feladatainak kiosztása, azok 
követése, a kampányban szereplő résztvevők 
üzleti teljesítményének mérésével magát a 
kampányokat is pontosan mérhetővé teszi. 

II-ügyfélszolgálat: jobb kiszolgálás, keve- 
sebb ráfordítás. A Microsoft CRM 3.0 segít 
ségével az informatikusok célirányos infor- 
mációkkal láthatják el a felhasználókat, hogy 
az általuk használt alkalmazásokkal kapcso- 
latos problémáikra mielőbb megoldást kap- 
janak. A Microsoft CRM beépített tudás- 
bázisában a kézikönyvek, a gyakran ismételt 
kérdések és a hibaelhárítási tippek azonnal 
elérhetőek, akár az egyes telephelyekért fele- 
lős munkatársak számára is. 

A beérkező problémák rögzítésére, auto- 
matikus továbbítására és a várólisták kezelé- 
sére szolgáló funkciók rögtön az illetékesek: 
hez irányítják a kéréseket. Az eszköz támoga- 
tást nyújt az ügyfélszolgálati vagy helpdesk- 
munkatársak ütemezéséhez és irányításához 
is, hogy az adott feladat elvégzésére alkalmas 
szakembert minél egyszerűbben meg lehes- 
sen találni. 

Vállalatirányítási rendszerek előtét-alkal- 


mazása. Az Outlookintegráció miatt számos 
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cég vállalatirányítási rendszereinek előtétal 
kalmazásaként is használja a CRMt-et, amely a 
Bizlalk adapterek segítségével számos - akár 
Microsoft, akár más - gyártó vállalatirányítá- 
si rendszerével képes szinkronizálni az ügyfe- 


lek törzsadatait és az üzleti tranzakciókat. 


A Dynamics CRM rövid technikai 
áttekintése 

A Microsoft Dynamics CRM 3.0 olyan jól 
bevált technológiákra épül, mint a .Net ke- 
retrendszer és az SOL Server, valamint ak 
tívan használja a lelke mélyén az Exchange 
Servert és az IIS-t is. Könnyen összeköthető a 
Bizlalk Serverrel, és ha további képességeket 
szeretnénk implementálni hozzá, használhat 
juk a Visual Studiót is erre a célra. 

A CRM szorosan együttműködik az Out 
lookkal, valamint a Microsoft Office részét 
képező Word, Excel, PowerPoint és más al 
kalmazásokkal, így a felhasználó megszo- 
kott, kényelmes Outlook-kkörnyezetben vé- 
gezheti munkáját, integrálva az ügykezelési 
mappákat a levelezőrendszer kezelőfelületé- 
be. Ez az Office-integráció azért nagyon fon- 
tos, mert a felhasználók ezáltal hamar meg- 
barátkoznak a CRM-mel, ha már amúgy is 
ezeket az alkalmazásokat használják a min- 


dennapi munkájukhoz. 


Tudom, mit vettél tavaly nyáron! 

A CRM tészeként a 3.0-s verzió megjelené- 
sével új üzletiintelligencia-szolgáltatásokhoz 
is hozzájuthatunk, ha segítségül hívjuk a 
Business Scorecard Managert is. Ezeknek az 
analitikus eszközöknek a megértéséhez ve- 
gyünk rögtön egy példát: egy, az ügyfeleit jól 
kezelő utazási iroda azt is meg tudja jósolni, 
idén mire vágyunk. Pihenésre, egzotikus út 
ra? Amennyiben emlékszik, hol nyaraltunk 
tavaly, mely ajánlatokat néztük meg alapo- 
sabban, akkor ajánlatai bizonyára célba ér- 
nek nálunk. 

A Microsoft Dynamics CRM analitikus 
eszközeinek célja az ügyfél jellemzőinek meg- 
határozása. Megismerhetők a fogyasztási szo- 
kásai, a fogyasztási szokásaihoz kapcsoló- 
dó információigénye. A Microsoft Dynamics 
CRM a megértett ügyfelekkel való törődés 
mindennapjait automatizálja, akár értékesíi- 
tésről, ügyfélszolgálatról, termékfejlesztésről 
vagy marketingaktivitásokról van szó. 

Nézzük meg szakmai szemmel, hogyan is 


működik ez a gyakorlatban! 





Üzleti intelligencia a Microsoft Dynam- ! rű lehet itt is egy mutatószámrendszerekre 


ics CRM-ben. Az üzletiintelligencia-rendsze- ! és teljesítménymutatókra épülő megoldást 
rekről, adatbányászatról sokat hallhatunk ! használni, amely gyors, könnyen áttekinthe- 


manapság, elsősorban az ERP-rendszerek- ! tő információkkal látja el az üzleti döntésho- 


kel (Dynamics NAV, AX) kapcsolatban. A 


Dynamics CRM mint a. vállalat ,kommuni- 


zókat, ugyanakkor lehetővé teszi a , lefúrást" 
a strukturálatlan adatok szintjéig. Ez az esz- 
kációs központja" természetesen szintén al ! köz aa Business Scorecard Manager. 
kalmas arra, hogy adatforrásként szolgáljon A scorecardok használatához és készítésé- 
különféle üzleti elemzésekhez. Eddig - meg- ! hez szükséges első lépéseket legkönnyebben 
felelő eszköz hiányában - nem hoztuk ösz- ! úgy sajátíthatjuk el, hogy letöltjük a www. 
szefüggésbe a CRM-alkalmazást a BImegok ! microsoft.com/dynamics/crm/using/down- 
dásokkal. A megfelelő eszköz - a Microsoft ! loads oldalról a mintaadatbázist a score- 
Office Business Scorecard Manager 2005 


- azonban nemrégiben megjelent, új lehető- 


card template-ekkel együtt, és megfigyeljük 
azok működését. Az I. ábrán látható egy, a 
ségeket nyitva mind az üzleti döntéshozók. ! CRM-ben tárolt üzleti lehetőségekből (op- 
nak, mind pedig a CRM-bevezetést végző ! portunity) BSM segítségével készített árbe- 
partnereknek. vételi tény-terv összehasonlító jelentés. A 
Kulcsfontosságú információk döntésho- ! képernyő bal oldalán a lehetőségek listané- 
zóknak. Az ügyviteli rendszerekhez hason- ! zete mellett láthatók a színes ikonokkal je- 
lóan a CRM is tartalmaz olyan mérhető / lölt teljesítménymutatók (Key Performance 


Indicator, KPI), illetve az aktuális trendek. 


üzleti adatokat, amelyeket felhasználhatunk 


A Home - Company Dashboard - Microsoft Internet Explorer 


File . Edit View — Favorites — Tools Help a 
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I. ábra. A scorecardok használata 


Jobb oldalon a két Excel Pivot Chart a lehe- 


tőségek időbeli eloszlását mutatja. 
Ezekből a kimutatásokból jól látható, 


üzleti döntéstámogatáshoz, hiszen a válla- 
lat kereskedelmi folyamatának jelentős ré- 
szét a CRM-alkalmazásban követjük nyo- 
mon: javarészt itt készül az értékesítési cik- ! hogy mely lehetőségek alakulnak a tervek 
lus dokumentálása, az ügyfelek visszajelzései ! szerint és melyek nem. Amennyiben a rész- 
pedig olyan információk, amelyek az ERP- ! letekre is kíváncsiak vagyunk, a listaelemek- 
rendszerekben esetleg egyáltalán nem is je- ! re kattintva megnyithatjuk a szóban forgó 
lennek meg. A hagyományos jelentéskészítő ! CRM-ekordot, tehát nem kell azt egy má- 
eszközök (SOL Reporting Services, Excel ! sik alkalmazásban visszakeresni. Lehetőség 


Pivottáblák) használata mellett ezért célsze- ! van arra is, hogy az elemek SOL Reporting 


Microsoft TechNet 





Services- jelentésekre, kapcsolódó listákra 
vagy bármilyen más információs weboldalra 
hivatkozzanak. 

hivatkozott 


Természetesen a jelentés 


származhat más rendszerekből - például a 


Dynamics AX vagy NAV adatbázisaiból - is. 


b 


E 


knzzsádkásl eket 


2. ábra. Architektúra és technikai háttér 


A 2. ábrán látható a BSM logikai architek- 
túrája, illetve a rendszerelemekkel kapcsola- 
tos üzleti és informatikai szerepkörök. 

Az adatbázisrétegben kap helyet a CRM 
adatbázisa és szükség szerint egy átmeneti 
adatbázis, amely nem elengedhetetlen ugyan, 
de számos érv szól használata mellett. 

Miért szükséges az átmeneti adatbázis? 
Az alkalmazások - így a CRM is - általá- 
ban a napi munkavégzés támogatására, azaz 
adatbevitelre és módosításra vannak opti 
malizálva, nem lekérdezésekre és számítá- 
sok végzésére. Az összetett, kalkulációkat is 
tartalmazó jelentések készítése erőforrás-igé- 
nyes művelet, átmeneti adatbázis használata 
nélkül jelentősen csökkentheti a rendszer 
teljesítményét, azaz akadályozhatja a napi 
munkavégzést. 

Az átmeneti adatbázisba történő üteme- 
zett adatáttöltés - amely történhet az SOL 
Server SSIS vagy a DIS technológiáinak 
használatával - biztosítja továbbá, hogy csak 
olyan üzleti információkból készüljenek je- 
lentések, amelyek valóban értelmezhetők is; 
ne szerepeljenek az adatok között még nyi- 
tott ügyletek; például időbeli változások nyo- 
mon követése esetén nem lezárt időszakok. 
Ezzel a módszerrel kiszűrhetők a jelentéseket 
torzító adatok. Az átmeneti adatbázis szolgál 
az OLAP-kockák alapjául, tehát struktúráját 
már ennek a célnak megfelelően lehet kiala- 


kítani, azaz lekérdezésekre optimalizálni. 


KENNY 





Az OLAP-kockák aggregált adatokat tar- 
talmaznak, a jelentések készítésekor így jó- 
val kisebb adathalmazból kell a rendszernek 
lekérdeznie és kalkulációkat végeznie. Az 
átmeneti adatbázis és az OLAP-kockák ké- 
szítése, dimenziók (dimension), perspektívák 
(perspective) és mérőszá- 
mok (measure) meghatá- 
rozása az adatbázis-admi 
nisztrátorok és a fejlesz- 
tők feladata. 

Az alkalmazásrétegben 
a CRMiwwebalkalmazás és 
a BSM scorecard-alkalma- 
zás ,végzi a munkáját, az 
felada- 


tokhoz szükséges eszkö- 


adminisztrációs 


zök és a felhasználói fe- 
lület már a megjelenítési 
rétegben kaptak helyet. A 
felhasználók - üzleti dön- 
téshozók -  SharePoint 
Portal oldalakon érhetik el a scroecardokat. 
Amennyiben pivottáblákat és chartokat is 
szeretnénk használni, azt az Officewebösz- 
szetevők (Office Web Components, OWC) 
segítségével tehetjük meg. 

Az  alkalmazásgazdák - 

TEZNETETET 


egy jól áttekinthető, köny- 


Threshokds 


General Properties 
s 


nyen használható grafi- 


testét 
kus eszközzel - a Business Én 
Scorecard Builderrel - ké- 
szíthetik el a jelentéseket. 

Fontos újdonság, hogy 
a KPl-definíciók is ezen a 
felületen hozhatók létre, 
lényegesen egyszerűbben, 
mintha azt a hagyomá- 
nyos módon, SOL Server 
2005 MDX (Multi Dimen- 
sional eXpression) lekér 


ue 


dezések írásával tennénk 
utóbbihoz 
is fejlesztői ismeretek és 

eszközök (Visual Studio) szükségesek, SOL 
2000-ben pedig még nem is létezett a KPL-k 


meg, ugyan- 


létrehozásához szükséges felület. 


Példa az indikátorok 
meghatározására 

Nézzük meg egy egyszerű példán keresztül, 
hogyan definiálhatjuk a teljesítménymutató- 
kat a BSM-en keresztül. A vizsgált üzletilehe- 
tőség-elemzést (mintaadatok, OLAP-kockák, 


Indicatot name: 


Banding Settngs 








srocecardok) a letölthető template tartalmaz- 

za. A 3. ábrán a Business Scorecard Builder 

Target Editor látható - itt határozzuk meg a 

terv-tény adatok összehasonlítására szolgá- 

ló indikátorok viselkedését. Esetünkben a 

tényadat (actual) a valós bevétel (actual rev- 

enue), a tervadat (target) a tervezett bevétel 

(estimated revenue). A Target Editorban a 

terv-tény teljesítések százalékos értékét há- 

rom szakaszra osztjuk, majd meghatározzuk, 
hogy az egyes szakaszok milyen üzleti jelen- 
tést hordoznak: 

z jó eredmény (On Target): jelen esetben a 
terv 66-100 százalékig történő teljesítése, 
ezt a könnyebb áttekinthetőség érdekében 
zöld színű ikonnal jelöljük; 

: még megfelelő érték (Slightly Off Target): 
a terv 33-66 százalékig történő teljesítése, 
ezt sárga ikonnal jelöljük; 

: nem megfelelő (Off Target): 33 százalék 
alatti teljesítés, piros színű ikon. 

A végeredmény a 1. ábrán látható: egy egy- 
szerű, jól áttekinthető felületen megjelennek 
az összefoglaló adatok, listanézetben a telje- 
sítménymutatókkal, amely a döntéshozókat 
azonnal tájékoztatja az ügyletek és tervek 


teljesítéséről. 
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Color Scheme and Boundáty Preview 


Ő Stahty OH Target 
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3. ábra. Egy KPI tulajdonságainak beállítása 


Akinek felkeltettük az érdeklődését, ne- 
tán szakmai kérdése merülne fel a Dynamics 
CRM-mel kapcsolatban, szívesen látjuk a 
TechNetklub.hu újonnan nyílt CRMllevele- 
zőlistáján, ahol igyekszünk mielőbb válaszol 
ni bármilyen kérdésre. 

Kovács László, 

(kovacsKosb.hu) System Builders 

Wentzel István 

(Istvan Wentzekemicrosoft.com) Microsoft Magyarország 
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Ha valaki készített már objektumorientált 
alkalmazást, amelyik használt adatbázist, 
esetleg XML-dokumentumokat, az tudja, 
hogy mennyire különbözik az egyes 
területek hozzáállása az adatok tárolásához, 
eléréséhez, a vezérléshez. 


em véletlen, hogy minden programozásról szóló könyv általában külön fejezetet szen- 

tel a SOL vagy az XML tárgyalásának, és egész tudományág van kialakulóban az ob- 

jektum-elációs leképezés körül. Anders Hejlsberg - a C$ nyelv tervezője - már régóta 
szeretett volna erre valamilyen elegáns választ adni. 

A Ct 3.0-val eljött az idő, most lehet olyan nyelvi újításokat bevezetni, amelyek segítenek 


áthidalni ezt a gondolkodásbeli különbséget. Ne ijedjünk meg! A Ct 3.0 még nem jelent meg, 
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Objektumok Relációs adat XML 


A LING technológiák körképe 


de Community Technology Preview változatban elérhető már, így megkezdhetjük a hozzászo- 
kást ezekhez a formulákhoz és gondolatokhoz. 


Fontos megemlíteni azt is, hogy a Visual Basic kedvelőinek sem kell csüggedniük, ugyanis 





kedvenc nyelvük 9.0-s változatában szintén 


elérhetők lesznek ezek az újdonságok. 


A Ct 3.0 (és a VB 9.0) része lesz az úgyneve- 
zett LINC technológia. Ez a Language Inte- 
grated (?uery (framewotk) - tehát a nyelvbe 
ágyazott lekérdező keretrendszer - kifejezés 
rövidítése. Találó az elnevezés, mert amellett, 
hogy a LINO segít a lekérdezésekben, kap- 
csolatot is teremt a korábban már említett 
világok között (a , link" szó angolul kapcso- 
latot is jelent). A LING keretrendszer több 
részre oszlik aszerint, hogy mely objektu- 
mokkal dolgozik. Az alapszintű LINO-rend- 
szer lehetővé teszi, hogy a szokásos nyelvi for- 
mulák között megfogalmazzunk lekérdezés 
jellegű programrészeket. Az adatbázisokkal 
való kapcsolat megteremtése a LING to SOL 
feladata, míg az XML-fájlok és formátumok 
világába a LING to XML vezet el minket. 


Jelenleg a LINO megjelenés előtti, CTP ál 
lapotban érhető el, ez a cikk a 2006. májusi 
CTP-változat alapján készül. A LINC kipró- 
bálásához szükség van a Visual Studio vala- 
melyik változatára (akár az ingyenes Express 
is megteszi), és ha arra telepítjük, akkor kap- 
juk meg az új Ct, vagy VB fordítót. Ha sze- 
retnénk használni a LINO to SOL designert, 
akkor nem elég az Express változat. A tele- 
pítés után nincs is más teendőnk, mint ki 
nyitni kedvenc Visual Studio-változatunkat 
és máris láthatunk egy új projekttípust, va- 
lamint a start menüben találhatjuk a LINO- 
dokumentációra és a mintaprogramokra mu- 


tató hivatkozásokat. 


Nézzünk egy nagyon egyszerű LINO-példát! 
Itt most szándékosan nem használjuk még 
sem a LINO to SOL-t, sem a LINE to 
XML-t, hogy először megérthessük a lekér- 
dezések szintaktikáját. Ha készítünk egy új 
LINO-konzolalkalmazást, akkor kapunk egy 
klasszikus program.cs fájlt. Szükségünk lesz 
egy lekérdezési forrásra, ehhez használjuk a 
System.Diagnostics névtér Process osztályát 
(ne feledjük a forrásfájl elején a using-ok kö- 
zé felvenni a névteret, ha az alábbi, rövid hi- 
vatkozást szeretnénk használni)! 

Ennek GetProcesses metódusa visszaadja 


nekünk az éppen futó folyamatok gyűjte- 








l 


ményét. Írjuk be az alábbi kódot a program 


Main metódusába: 


var expr — from s in Process.GetProcesses() 
select s.ProcessName; 

foreach (string i in expr) Console.WriteLine(i); 

Console.Readline(); 


Ha lefuttatjuk ezt a programot, és van 
jogunk a listázáshoz, akkor a konzolon lát 
hatjuk az éppen futó folyamatok listáját. 


Elemezzük egy kicsit ezt a programot! 


A lekérdezés elemei 

Egy pillanatra tegyük félre a szokatlan , var" 
kifejezést a bal oldalon, és nézzük a jobb 
oldalt. Igencsak ismerős kifejezésekkel van 
dolgunk, hiszen ezeket már az SOL nyelvből 
ismerhetjük. Mégis láthatjuk, hogy objek- 
tumorientált kóddal van dolgunk, hiszen a 
kiválasztott elemek típusát mi határozzuk 
meg a select után, amikor a listában szereplő 
Process típusú objektumokról a nevüket vesz- 
szük be a lekérdezésbe. A LINC lehetővé te- 
szi, hogy ilyen és ehhez hasonló lekérdezése- 


ket intézzünk minden olyan osztályra, ame- 


tum taglalja. Aki dolgozott már SOL-el, az 
hamar otthon fogja magát érezni, de örül 
ni fog az objektumorientált lehetőségeknek. 
Egy ilyen lehetőséget láthatunk az alábbi le- 


kérdezésben is: 


var expr — from s in Process.GetProcesses() 
where s.ProcessName.Length — — 
orderby s.WorkingSet descending 
select s.ProcessName; 


Ezzel kiválaszthatjuk az öt karakter hosz- 
szúságú névvel rendelkező processzeket a 
working set mérete szerint csökkenő sorba 


rendezve. 


És mi történik a típusokkal? 
Aki szereti az erős típusosságot, de dolgozott 
már gyengén típusos környezetben, az bizo- 
nyára kellő döbbenettel konsta- 


New Project 


tálta a var kulcsszó megjelené- 


Project types: 
sét, ami sok nyelvben a megha- Tá 
Starter Kits 
tározatlan és megváltoztatható agég 
Workflow 
típusok jelzése (gondoljunk csak 2.Visval Cs 
Windows 
, , íz NET Framewo: rk20 
például a JavaScriptre). A CH Ottce 
11- Smart Device 


Database 
Starter Kits 


,vedd a kifejezés jobb oldalán lest 


Workflow 


3.0-ban a var annyit jelent, hogy 


tunk meg feltételeket. Ezek teszik lehetővé, 
hogy a feltételektől függetlenül implementál 
juk az egyes kulcsszavaknak megfelelő metó- 
dusokat, majd azokat a nyelv részeiként egy- 
más után fűzzük. De ne is merüljünk mély- 
re! Aki szeretne, utána tud olvasni a LIN€ 
mélyebb lelkivilágának és kiterjeszthetőségé- 
nek az MSDN oldalain. 


LINO to SOL 


Most, hogy már van egy hasznos és rugalmas 
lekérdezőeszközünk, jó lenne minél több- 
re használni. Az egyik kézenfekvő lehető- 
ség a relációs adatbázisok lekérdezése. Ma 
ez egyfajta skizofrén tudatállapotot igényel, 
és folyamatosan váltanunk kell fejben az 
adatbázis funkcionális és a Ct objektumos 
megközelítése között. Nem is beszélve arról, 


hogy mennyi alacsony szintű, üzemeltetés 


sz 


Ve a. a L2 [ocuu] I 
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Console application that uses the Cs LING Compiler 


előálló típust, és legyen ennek 


Name: LINOConsoleápplicationi 


CAUserorevententDocumentst Visual Studio 20051Projects - 


LINOConsoleApplicationi 


a változónak az az erős típusa". tscéüési 








NOTT TT án tTotáto X 


Solution Name: [U] Create directory for solution 





Don Box, Anders Hejlsberg: The Ling project: 
http://msdn.microsoft.com/ library/en-us/dndot- 
net/html/lingprojectovw.asp 

Ling May 2006 Preview: Attp://www.microsoft. 
com/downloads/details. aspx?familyid-1E902C21- 
340C4D13-9FO4-70EBSESDCEFAG displaylang-en 
The ADO.NET Entity Framework Overview: 
http://msdn.microsoft.com/ library /en-us/ 
dnys05/htm[/ADONETEnFrmOvw.asp 

Bling preview: 
http://www.asp.net/sandbox/app. bling.aspx 





lyik implementálja az IEnumnerable inter- 
fészt. Ilyen például a Process.GetProcesses() 
által visszaadott tömb, de sok ilyen objektu- 
mot ismerünk még, illetve magunk is köny- 
nyen elkészíthetjük őket. 

A kötelező from és select mellett többek 
között van lehetőségünk szűrésre (where), 
rendezésre (orderby) vagy akár csoportosítás- 
ra is. Számos más lehetőségünk is van, eze- 
ket részletesen a LINO-kel együtt települő 
, Standard (?uery Operators.doc" dokumen- 


 NUÁR 


Ezzel egyszerre megtarthatjuk 





az erős típusosságot; amellett, 





hogy nem kell azon gondolkod- 
nunk egyfolytában, hogy a jobb 
oldalon található, akár egészen bonyolult le- 


kérdezés végül milyen típust eredményez. 


A LING alternatív megfogalmazása 

A korábban bemutatott lekérdezésforma a 
legrövidebb, legkönnyebben olvasható for- 
ma. Ha szeretnénk tudni, hogy mi zajlik a 


háttérben, akkor cseréljük le az alábbira: 


var expr — Process.GetProcesses() 
Where(s —— s.ProcessName.Length —— 5) 
OrderBy(s —— s.ProcessName) 
Selectlís —— s.ProcessName); 


Itt azt láthatjuk, hogy a korábbi lekérdezés 
típusú kódból valójában a fordító mit készít, 
és ezzel betekintést nyerhetünk a LINC? mű- 
ködésébe. A zárójelben található kifejezések 
az úgynevezett Lambda-kifejezések, ezek ha- 
sonlítanak a névtelen metódusokra abban, 


hogy valamilyen művelet elvégzésével adha- 


A LING projekt léterehozása Visual Studióval 


jellegű kódot kell írnunk (például connec 
tion-objektumok, lekérdezések összefűzése 
stb). Ehelyett a LING to SOL egy egyszerű 
szintaktikával kínál meg minket (a minta a 


LINC to SOL dokumentációból származik): 


[Table(Name—"Customers")] 
public class Customer 


[Column(ld—trve)] 
public string CustomerlD; 
[Column] 

public string City; 


//Ez már valahol a program részben van 
DataContext db — new DataContext(connectionString); 
Table CCustomer— Customers — db.GetTable CCus- 


tomer— (); 

var g — 
from cin Customers 
where c.Cty —— "London" 
select c; 


foreach (var cust in g) Console.Writeline("id — (0), City 
— (1, cust.CustomerlD, cust.City); 


di 





A végén található két sor 
már ismerős lehet, ami pe- 
dig előtte történik, az nagyon 
egyszerű: először a LINE to 
SOL által definiált attribútu- 
mok segítségével készítünk 
egy osztályt, amit hozzárende- 
lünk egy, az adatbázisban tá- 
rolt táblához, illetve az osz- 
tály mezőit a tábla mezőihez. 
Ezután már tudjuk is használ 
ni, a DataContext segítségével 
megadjuk, hogy melyik adatbá- 
zist használjuk egy connection 
stringgel, majd pedig a Get 
Table hívásával kaphatunk egy 
hivatkozást a valódi táblára. 

Ezután a megszokott mó- 
don folytathatjuk a lekérdezéseket objek 


tumorientált módon. 


A másik, nem kifejezetten objektumorien- 
tált adatforma az XML. Ez a dokumentum 
alapú adatforma többféleképpen is feldolgoz- 
ható. Csak a .Net XML névterei legalább két 
lehetőséget adnak, amelyek közül az egyik 
inkább a dokumentum jellegű szekvenciális 
feldolgozás (a readerek világa), a másik pedig 
a teljes struktúrát a memóriába töltó DOM 
(Document Object Model) lehetősége. Most 
ezek helyett, illetve mellett kaphatunk egy 
közvetlenül a programozási nyelvbe integrált 
XML nyelvű definíciós és lekérdezőformát. 
Lássunk először egy példát a minták közül 
arra, hogy hogyan lehet egy új XML-elemet 


definiálni: 


var e — new XElement("Ember, 
new XAttribute(" Programozó", true), 
new XElement("Név", "Kóder Károly"), 
new XElement("Kor, 319); 

var s — elToString(); 

Console Writeline(5); 

Console.ReadLine(); 


Az eredményt megjelenítve láthatjuk, 
hogy milyen egyszerű ez. 

Ha az IntelliSense segítségével végignéz- 
zük, hogy az objektumnak milyen tulajdon- 
ságai és metódusai vannak, akkor azonnal 
láthatjuk azt is, hogy egyrészt miként tudjuk 
objektumorientált eszközökkel manipulálni 


ezt az XML-modellt, másrészt, hogy miként 


from c in db.Customers 
where c.City —— "London" 
select c.CompanyName 


SELECT CompanyName 
FROM Cust 
WHERE City -— "London" 


Application 


LING Cuery 


SubmitChanges() 


egeg:iel 


SOL Cuery DML or SProcs 





A LING to SOL architektúrája 


lesz alkalmazható erre az XML-modellre a 
LINC. Ezzel akár komplex lekérdezéseket is 
alkothatunk, amelyek összekötnek a memó- 


riában található adatforrásokat a relációs és 


az XML-adatokkal. 


Adatbázis alapú alkalmazásoknál számos 
unalmas órát (napot) okoznak azok a mű- 
veletek, amikor az egyszerűbb alapművele- 
teket végző felületeket készítjük el (például 
update, delete stb.). Rutinosabb versenyzők 


db.Customers Add(c1); 
c2.City — "Barcelona"; 
db.Customers.Removeíc3); 


INSERT INTO Cust ... 
UPDATE Cust ... 
DELETE FROM Cust ... 


Microsoft 


legenerálja az adatbázisunk we- 
bes felületét. Ebben lehet majd 
alapműveleteket végezni (cre- 
ate, read, update, delete), illet 
ve lehet navigálni a sémában; 
ismeri a kulcsok mentén az 
összefüggéseket, és az adatok 
lapozását is lehetővé teszi. Ezek 
az oldalak jól használhatók az 
alkalmazásunk adminisztrá- 
ciós felületein vagy akár ma- 
gában az alkalmazásban is. A 
Bling a LINO-re épül, jelenlegi 
változata a májusi CI P-t hasz- 
nálja. Az még nem látszik telje- 
sen, hogyan fog beilleszkedni a 
nagy egészbe, de mindenesetre 
ígéretesnek tűnik. Mostani ál 
lapotában megtekinthető a http://www.asp. 
net/sandbox/app. bling.aspx címen. 


Természetesen egy ilyen rövid cikkben épp- 
hogy csak a felszínt lehet megkapargatni, a 
LINC mögött sokkal több van. Komplex és 
kibővíthető keresések, másfajta adatforrá- 
sok - például a LING to DataSet vagy az új 
ADO.NET Entity Framework, ami az objek- 
tumrelációs leképezés teljes problémakörére 


próbál átfogó választ adni. Akinek megtet 


EH file.//C/Users/leventen/Documents/Visual Studia 2005/Prajects/IINO€ConsaleApplication [I INOC a... ! 


InoTazk 


Az éppen futó folyamatok listája a konzolon 


persze már generálják ezt a kódot. Ebben a 
generálásban nyújt segítséget az ASPNEL 
fejlesztőknek a Bling. Ez egy parancssori 
eszköz, és ha megadunk neki egy adatbázist, 


egy mappát és egy virtuális mappát, akkor 





szett a LING), javasoljuk, hogy próbálja ki, 

illetve a keretes cikkben felsorolt oldalakon 
olvasson utána a többi újdonságnak is! 

Nagy Levente 

(nagy.levente Dmicrosoft.com) Microsoft Magyarország 
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KONKURENCIAKEZELÉS 
AZ SOL SERVER 


2005-BEN 


Az SOL Server 2005 fejlesztői régi adósságot törlesztettek: 
megvalósították a versenytársaknál már több mint egy évtizede 


sikerrel alkalmazott optimista konkurenciakezelési modellt. 


z adatbázis-kezelő rendszerekkel szembeni egyik legkomolyabb kihívás, hogy egyszerre 
biztosítsák az adatok gyors, konzisztens és konkurens kezelését. A megfelelő teljesít- 
mény alapkövetelmény: senki nem szeret perceket várni egy-egy számlatétel rögzítésé- 
re, és a gyártósor sem állhat addig, amíg az adatkezelőnk feldolgozza az egyes munkafázisok 
adatait a következő előkészítéséhez. Minden alkalmazás valamilyen szabályrendszer alapján 
kezeli az adatokat: legyenek ezek nagyon vagy kevésbé szigorúak, az adatbázis-kezelőnek biz- 
tosítania kell, hogy az adatok megfeleljenek ennek a szabályrendszernek, azaz konzisztensek 
legyenek. Az alkalmazásokat általában egyszerre több, akár több ezer felhasználó is használja. 
Az adatbázis-kezelőnek megfelelő teljesítmény mellett, az adatbázis konzisztens állapotát folya- 


matosan fenntartva kell biztosítania a konkurens felhasználást. 


Teljesítmény, konzisztencia és konkurencia 

Nagyon egyszerűen belátható, hogy e három tényezőt nem kezelhetjük egymástól függetle- 
nül, azaz minél erősebb adatkonzisztenciára törekszünk, annál nehezebb a konkurens hozzá- 
férések koordinálása, és ez bizony csak a teljesítmény csökkenésének árán valósítható meg. 
Amikor tehát a konkurens és konzisztens adatkezelés szabályozásáról beszélünk, mindig te- 
kintettel kell lennünk arra, hogy minél konzisztensebb, pontosabb adatkezelést szeretnénk 


megvalósítani, annál nagyobb árat kell ezért fizetnünk. 


Tranzakciók 

Az adatbázist egy adott időpontban konzisztensnek nevezzük, ha az adatbázisban tárolt ada- 
taink megfelelnek egy bizonyos, rögzített szabályrendszernek. A szabályok sokfélék lehetnek, 
az adatok egyediségétől kezdve egészen az olyan összetett szabályokig terjedhetnek, hogy pék 
dául a zárás után a főkönyvi számla egyenlege nulla legyen. 

Az adatbázistól általában nem várhatjuk el, hogy minden időpillanatban konzisztens le- 
gyen, mivel lehetnek olyan összetett műveleteink, amelyek végrehajtása közben az adatbázis 
egyes részei óhatatlanul inkonzisztens állapotba kerülnek. Gondoljunk például arra az esetre, 
hogy az egyik számláról már levontuk az összeget, de a másik számlához még nem adtuk hoz- 


zá, vagy hozzáadtunk egy tételt a számlához, de a számla egyenlegét még nem módosítottuk. 


Az átmeneti inkonzisztens helyzet a művele- 
tet éppen végrehajtó folyamat szempontjából 
nem okoz semmilyen problémát, ha az össze- 
tartozó műveletek mind végrehajtódnak, és 
a módosítások sikeresen be is kerülnek az 
adatbázisba. A helyzet azonban teljesen más 
az adatbázisban műveleteket végző konku- 
rens folyamatok szempontjából vizsgálva. Ha 
a konkurens folyamat beleolvas az átmeneti 
leg inkonzisztens adatokba, és azokat felhasz- 
nálva módosításokat végez az adatbázison, az 
rövid idő alatt akár az adatbázis teljes inkon- 
zisztenciáját is eredményezheti. Még súlyo- 
sabb lehet a helyzet, ha két folyamat egymás 
tudta nélkül egyszerre módosítja ugyanazo- 
kat az adatokat. 

A konzisztens és konkurens adatmódosí- 
tás megoldására a tranzakciók szolgálnak. A 
tranzakciók biztosítják az összetartozó műve- 
letek egyszerre történő érvényesítését (,ato- 
miság"), a tranzakciók végrehajtása utáni 
adatkonzisztenciát (, konzisztencia"), az egyes 
folyamatok átmeneti inkonzisztens állapo- 
tának más folyamatok előli elzárását (,izo- 
láció") és a műveletek eredményének tartós- 
ságát (, tartósság"). Ezt a négy tulajdonságot 
jelöljük az ACID betűszóval az angol elne- 
vezések (Atomicity, Consistency, Isolation, 


Durability) kezdőbetűi alapján. 
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Egy rendszert tranzakció-kezelő rendszer- 
nek nevezünk, ha biztosítja a tranzakciók 
ACID szerinti kezelését. Az ACID-tulajdon- 
ságok közül az atomiság és a tartósság egysze- 
rűen definiálható követelmények, azaz vagy 
a tranzakció minden művelete érvényesül és 
tárolódik az adatbázisban, vagy egyik sem, 
tehát az adatbázis a tranzakciót megelőző ál 
lapotba kerül vissza. A konzisztencia és az 
izoláció azonban sokkal bonyolultabb fogak 
mak, és a gyakorlatban csak együttesen értel 
mezhetőek. 

Ma már minden komoly adatbázis-kezelő 
rendszer megfelelően kezeli a tranzakciókat, 
azonban mindegyik más-más módon valósít 
ja meg azokat. Az SOL Server 2005 a tranz- 
akciók kezelését több együttműködő kompo- 
nens segítségével oldja meg. Mivel az összes 
komponens tárgyalása meghaladja e cikk ter- 
jedelmi lehetőségeit, a továbbiakban csak a 
tranzakció-kezelés konkurenciaproblémáira 
(konzisztencia, izoláció), és azok megoldásá- 


ra koncentrálunk. 


Konkurenciakezelési modellek 

A konkurenciakezelés alapvető kihívása a kö- 
zös erőforrásokhoz való hozzáférés szabályo- 
zása. Egy relációs adatbázis-kezelő esetében 
közös erőforrás az adatbázis, a tábla, az adat 
lap, a sor, a memória, a lekérdezéseket futta- 
tó végrehajtási szál, és minden egyéb olyan 
rendszerelem, amelyen a felhasználói folya- 
matoknak osztozniuk kell. Az SOL Server 
2005 a felhasználói folyamatok által közvet 
lenül kezelhető erőforrások (adatbázis, táb- 
la, adatlap, adat vagy indexsor) konkurens 
hozzáférésének szabályozását teszi lehetővé, 
míg a belső erőforrásokhoz (memória, végre- 
hajtási szálak, belső adatstruktúrák) történő 
hozzáférést automatikusan szabályozza. 

Az adatbázis-kezelők két alapvető konku- 
renciakezelési modellt alkalmaznak: a pesz- 
szimista és az optimista modellt. Az SOL 
Server 2005 mindkét modellt megfelelően 


támogatja. 


Pesszimista konkurenciakezelés 

A pesszimista konkurenciakezelés lényege, 
hogy a használandó erőforrásokat lefoglal 
juk, és mindaddig nem szabadítjuk fel, amíg 
azokkal műveleteket végzünk. A megközelí- 
tés azért pesszimista, mivel arra számít, hogy 
az erőforrást más is le akarja foglalni, és ezt 


igyekszik önző módon megakadályozni, az- 


JANUÁR 


az megszerezni és megtartani az erőforrást, 
ameddig csak szükség lehet rá. 

Ez a gyakorlatban azt jelenti, hogy az adat 
olvasó tranzakciók nem engedik más tranz- 
akcióknak írni az adatokat mindaddig, amíg 
be nem fejezik az olvasást, az adatokat író 


tranzakciók pedig minden más műveletet 
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Az SOL Server 2005 tranzakciós lehetőségeinek áttekintése 


(írást és olvasást) megakadályoznak, a tranz- 
akció-kezelés terminológiájával élve , blok- 
kolják" a konkurens folyamatokat a tranzak- 
ció befejezéséig. 

A pesszimista konkurenciakezelés általá- 
ban magas szintű konzisztenciát, de kisebb 
konkurenciát tesz lehetővé. A folyamatos 
blokkolás az erősen konkurens rendszerek: 
ben komoly teljesítményproblémákhoz és 
számos esetben a folyamatos munkát nehezí- 
tő feloldhatatlan blokkoláshoz, holtpontok- 
hoz (angolul , dead-lock") vezet. 


Optimista konkurenciakezelés 
Az optimista konkurenciakezelés alapelve 
az, hogy az erőforrásokat csak a szükséges 
mértékben foglaljuk le, és a műveletek elvég- 
zése után gyorsan felszabadítjuk, hogy más 
tranzakciók rendelkezésére álljanak. Ez opti- 
mista hozzáállás, mert arra számítunk, hogy 
az általunk használni tervezett erőforrás ren- 
delkezésre áll, amikor szükségünk van rá. 
Az optimista konkurenciakezelés általá- 


ban alacsonyabb szintű konzisztenciát, de 


Snapshot 
olvasó tranzakció 





nagyobb konkurenciát tesz lehetővé, mivel 
a legtöbb megvalósításban az olvasók nem 
blokkolják az írókat, és az írók nem blok 
kolják az olvasókat. Az optimista megközelí- 
tés velejárója, hogy ugyanazt az adatot több 
tranzakció is megpróbálhatja módosítani. 


Ezt azonban ebben az esetben sem engedhet 


Blokkolt, vár 





Zárolna 


Blokkolt, vár, 
visszagörgetődik 


Tranzakció 
indítása szerinti 
állapotot olvas 


jük meg (belátható, hogy ez a teljes káoszhoz 
vezetne), ilyenkor az optimista tranzakciónak 
is várnia kell, amíg az erőforrás felszabadul, 
vagy vissza kell azt görgetnünk, és újra meg 
kell próbálnunk a tranzakció végrehajtását. 
Fontos hangsúlyoznunk, hogy a pesszi- 
mista szónak semmilyen leminősítő jellege 
nincs, nem arról van szó, hogy a pesszimista 
konkurenciakezelési modell rosszabb vagy 
kevésbé hatékony, mint az optimista. A két 
modellt önállóan vagy egymás mellett al 
kalmazva különböző feladatok megoldására 


tudjuk használni. 


Zárolás és verziókezelés 

Az SOL Server 2005 a konkurens hozzáférés 
szabályozására a zárolást és a verziókezelést 
alkalmazza. A zárolás a pesszimista konku- 
renciakezelés legfontosabb eszköze. Az SOL 
Server az erőforrásokra elhelyezett zárak se- 
gítségével szabályozza, hogy melyik tranz- 
akció milyen módon férhet hozzá az adott 
erőforráshoz. A verziókezelés az optimista 


konkurenciakezelést támogatja azáltal, hogy 


ir 








a módosított adatok módosítás előtti állapo- 
tát egy verziótárban tárolja, és a többi tranz- 


akció rendelkezésére bocsátja. 


Zárolás 
Az SOL Server az adatbázisokon, táblákon, 
adatlapokon, index és adatsorokon helyez el 
különböző zárakat a hozzáférés szabályozásá- 
ra. A zárolás automatikus, és legtöbbször a 
sor szintjén történik, azaz a szerver adat- vagy 
indexsorokat zárol. A rendszer által hasz- 
nált két legfontosabb zár az olvasásokhoz 
használt osztott zár (,shared lock" - ,§5"), 
és az adatmódosításhoz használt kizárólagos 
zár (,exclusive lock" - ,X"). Az SOL Server 
számos egyéb zártípust is használ - mint 
például a módosítást és törlést megelőző mó- 
dosítási zár (,update lock" - , U") vagy a zá- 
rolási szándékot jelző szándék zárak (, intent 
lock" - , IX", , IS") -, amelyek táblára vagy 
adatlapra alkalmazva az 
alacsonyabb szintű erőfor- 
rások zárolását jelzik. 


USE master 
GO 


Zárakat az erőforrások: 
ra zártulajdonosok (,lock 
owner") helyezhetnek el. 
Zártulajdonos lehet egy  §9 
munkamenet, egy tranz- 
akció vagy egy kurzor. A 


továbbiakban csak tranz- 
USE PeldaDB 


-01. kapcsolat: 
--iz Adat mező tartalma "AAA! . 


Megjegyezzük, hogy a blokkolás önmagában 
nem probléma, hanem a tranzakció-kezelés 
természetes következménye. 

Azt, hogy az SOL Server milyen zárakat 
helyez el az erőforrásokra, és azokat mennyi 
ideig tartja fenn, a tranzakció-izolációs szin- 


tek segítségével szabályozhatjuk. 


Verziókezelés 

A verziókezelés alapértelmezetten kikap- 
csolt állapotban van, és az ,ALLOW 
SNAPSHOT ISOLATION" vagya , READ 
COMMITTED SNAPSHOT" adatbázis-op- 
ciók bekapcsolásával aktiválhatjuk. A két 
opcióra az izolációs szintek tárgyalásánál visz- 
szatérünk. Amennyiben az opciók valamelyi- 
ke bekapcsolt állapotban van, az SOL Server 
automatikusan elkezdi lementeni az adatmó- 
dosító műveletek során megváltozott sorok 


módosítást megelőző állapotát a tempdb-be. 


-n1. kapcsolat: az ALLOW SNAPSHOT ISOLATION 
-egpció bekapcsolása 


ALTER DATABASE PeldabB SET ALLOW SNAPSHOT ISOLATION ON 


tranzakció indítás. 


akciókkal foglalkozunk. GO 
Egy erőforrásra több 
He BEGIN TRAN 
tranzakció is helyezhet el UPDATE Ti SET Adat - "XXX! WHERE ID-1 


zárat, amennyiben a zá- 
rak egymással kompatibi 
lisak. A pesszimista kon- 


kurenciakezelés esetén az, 


-2. kapcsolat: 
-a- indítása és sikeres konkurens olvasás. 
--Az eredmény "AMA! . 


a SNAPSHOT tranzakció 


3ET TRANSACTION ISOLATION LEVEL SNAPSHOT 


hogy egy tranzakció hoz Go 

záférre valamilyen erőfor 

ráshoz olvasási vagy írási MEN etévetáN e 
céllal, azon múlik, hogy 
az erőforráson milyen zá- 
rak vannak. Amennyiben 
a tranzakció által kért zár nem kompatibi- 
lis a már meglévő zárakkal, a tranzakciónak 
várnia kell a meglévő zárak feloldására, azaz 
blokkolt állapotba kerül. Az osztott zárak 
kompatibilisak egymással, azaz több tranz- 
akció olvashatja ugyanazt az adatot. A ki 
zárólagos zárak egyik-másik zártípussal sem 
kompatibilisek, tehát az írók blokkolják az 
írókat és az olvasókat is. Az egyes zárak egy- 
mással való kompatibilitását az SOL Server 


egy kompatibilitási mátrix alapján ellenőrzi. 


JELECT Adat FROM T1 WHERE ID-1 


A Snapshot tranzakció működése 


Amennyiben egy sort több, párhuzamo- 
san futó tranzakció is módosít, az SOL 
Server a változatokat egy láncolt listában őr- 
zi meg, amely az újabb verzióktól a régebbi 
verziók felé halad. A verziókat az SOL Server 
mindaddig megőrzi, amíg azokra szükség le- 
het, majd automatikusan kitakarítja a verzió- 
tárból. Mivel ezáltal az adatsorok módosítá- 
sok előtti minden konzisztens állapota meg- 
őrződik, az optimista konkurenciakezelést 


alkalmazó tranzakciók mindig hozzáférnek 





azokhoz, így az írók nem akadályozzák az ol 
vasókat. 

A verziókezelés módját és a verziók meg- 
őrzésének időtartamát a tranzakció-iizolációs 


szintek határozzák meg. 


Tranzakció-izolációs szintek 

A tranzakció-izolációs szintek azt határozzák 
meg, hogy a konkurens tranzakciók adatmó- 
dosító műveletinek hatása milyen mérték: 
ben van egymástól elzárva, izolálva. A tranz- 
akció-izolációs szint mindig az azt alkalmazó 
tranzakció szempontjából határozza meg az 
izoláció módját. Az SOL Server 2005 négy- 
féle pesszimista (Read Uncommitted, Read 
Committed, Repeatable Read, Serializable) 
és kétféle optimista (Read Committed 
tranzakció-izolációs 


Snapshot, Snapshot) 


szintet különböztet meg. 


A , Read Uncommitted" izolációs szint 
A , Read Uncommitted" a leggyengébb izo- 
lációs szint. Ezen a szinten az olvasók nem 
blokkolják az írókat, és az írók nem blok 
kolják az olvasókat, mivel az olvasók nem 
alkalmaznak osztott zárakat, és figyelmen 
kívül hagyják a kizárólagos zárakat. Az SOL 
Server 2005 semmilyen szinten nem engedi 
meg ugyanannak az erőforrásnak több tranz- 
akció általi írását, így ezen a szinten sem, 
azaz az írók mindig blokkolják az írókat. A 
kizárólagos zárak tehát az adatmódosítástól 
kezdve a tranzakció befejezéséig fennállnak. 
(Ez minden izolációs szintre igaz, úgyhogy a 
továbbiakban ezzel nem foglalkozunk.) 

Ha egy tranzakció ,Read Uncommitted" 
izolációs szinten van, akkor beleolvashat 
más tranzakciók nem véglegesített adatába. 
Ez inkonzisztens vagy más szóval , piszkos" 
olvasáshoz vezet, és az az eredménye, hogy 
nem konzisztens vagy később érvénytelení- 
tett adatot olvasunk, tehát az eredmény nem 
mindig lesz pontos. Hangsúlyozzuk, hogy ez 
nem feltétlenül rossz viselkedés, az esetek je- 
lentős részében elfogadható, tehát mindig az 
adott szituációnak megfelelően kell értékel 
jük: ez a viselkedés nemkívánatos egy bank- 
számla nyilvántartásban, de teljesen elfogad- 
ható lehet egy kereskedelmi rendszer trend- 
analízisjelentésében. 

Bár a , Read Uncommitted" modell keve- 
sebb zárat alkalmaz, mégis pesszimista ab- 
ban az értelemben, hogy azért nem zárol, és 


azért nem veszi figyelembe a zárakat, mert 
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azt feltételezi, hogy mások zárolnak, és csak 


mások , piszkos" adataihoz férhet hozzá. 


A , Read Committed" izolációs szint 
A ,Read Committed" izolációs (rövidítve 
RCD) szint az SOL Server 2005 alapértelb 
mezett tranzakció-izolációs szintje. Az RCI 
csak a tranzakciók által véglegesített adatok 
olvasását teszi lehetővé, nem engedi meg a 
piszkos olvasást. Ezt azáltal éri el, hogy az ol 
vasáshoz osztott zárat alkalmaz az erőforráso- 
kon. Mivel az osztott zár nem kompatibilis az 
írók által alkalmazott kizárólagos zártal, áz 
RCI tranzakciónak mindaddig várnia kell, 
amíg a kizárólagos zárak feloldódnak. Az 
RCI tranzakciók adatolvasás közben blok- 
kolják az írókat, mivel az olvasás idejére osz- 
tott zárakat alkalmaznak. A blokkolás tehát 
kétirányú, az írók blokkolják az olvasókat, 
és az olvasók blokkolják az írókat. Ez alapve- 
tően nem probléma, természetes viselkedés 
mindaddig, amíg nem okoz túlzott várakozá- 
si időket és kezeletlen holtpontokat. 

Az RCI tranzakciók tervezése komoly 
elemző munkát kíván: tisztában kell len- 
nünk azzal, hogy milyen tranzakciók fognak 
futni a rendszerben, azok pontosan milyen 
erőforrásokat, milyen módon és meddig zá- 
rolnak. A leggyakoribb megoldandó feladat 
a hosszabban futó lekérdezések által okozott 
írási problémák kezelése, mivel a hosszan fu- 
tó olvasási műveletek számos írási műveletet 
blokkolhatnak, amelyek aztán más folyama- 
tokat blokkolnak. Ez gyakran nem várt és 
nem kezelt holtpontokhoz vezet - ugyan- 
akkor a problémák megfelelő tervezéssel és 
alkalmazásfejlesztési szabályok kialakításával 


elkerülhetők, illetve minimalizálhatók. 


A , Repeatable Read" izolációs szint 

A , Repeatable Read" izolációs szint bizto- 
sítja az elolvasott adatok tranzakción belüli 
változatlanságát. Ez magában foglalja az RCI 
szintet, és megszigorítja az osztott zárak keze- 
lését azáltal, hogy az osztott zárakat nemcsak 
az olvasási művelet végéig, hanem a tranz- 
akció befejezéséig fenntartja. Ezáltal a már 
egyszer elolvasott adatot senki sem módosít 
hatja a tranzakció végéig. Nyilvánvaló, hogy 
a , Repeatable Read" izolációs szinten futó 
tranzakció egyidejűleg több adatot zárol, és 
a zárak tovább állnak fenn, mint az RCI 
tranzakciók esetében. Ez hosszabb blokko- 
lásokat, több holtpontot és ezáltal csökkenő 


ANUÁR 


konkurenciát eredményez. Sok konkurens 
felhasználó esetén ez a rendszer komoly telje- 
sítménycsökkenéséhez vezethet. 

A ,Repeatable Read" izolációs szintet 
gyakran használjuk arra, hogy bonyolultabb 
lekérdezéseket kisebb lépésekre bontva fut 


NT ? 


adathalmazokon semmilyen módosítást nem 
engedhetünk meg a tranzakció végéig. Ilyen 
tranzakció lehet például egy bankszámla- 
mozgás-művelet, amellyel pénzt emelünk le 
a számláról, majd a számla egyenlegét módo- 


sítjuk, naplózzuk és könyveljük. A folyamat 
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Sorverziók lekérdezése 


tassunk le, miközben a lekérdezések között 
fenntartjuk a zárakat a konzisztens ered- 
mény elérése érdekében. Tipikus példa er 
re például egy eredménykimutatás készítése, 
amely általában számos lekérdezés futtatását 
teszi szükségessé úgy, hogy közben az adatok 
ne változzanak. Ilyen esetben a , Repeatable 
Read" kiváltható az új , Snapshot" izolációs 
szinttel, ahogyan azt később látni fogjuk. 
A , Serializable" izolációs szint 
A , Serializable" a legszigorúbb tranzakciós 
izolációs szint. Azt biztosítja, hogy a konku- 
rens tranzakciók úgy fussanak le, mintha 
egymás után hajtanánk őket végre. Ez azt 
feltételezi, hogy a tranzakció az adatbázist 
minden pillanatban aktuális és konzisztens 
állapotban látja, az általa egyszer már elol 
vasott adatok nem változnak, és új adatok 
sem keletkeznek. A , Serializable" izolációs 
szinten futó tranzakció az olvasási zárakat 
a tranzakció végéig fenntartja, és azt is meg- 
akadályozza, hogy az általa futtatott lekérde- 
zések eredményhalmazába új adat kerüljön 
be. Ezt a lekérdezések feltételeiben szereplő 
mezőkön lévő indexek kulcstartományainak 
zárolásával - vagy megfelelő index híján, a 
táblák zárolásával - éri el. 

A , Serializable" nagyon magas szintű kon- 
zisztenciát biztosít. Olyan esetekben hasz- 


náljuk, amikor az egyszer már elolvasott 


FROM sys.dm tran version store 
WHERE database id - DB IDí("PeldaDB") 





status ! 
17 72057594038452224 0 


során nem engedünk új számlamozgást rögzí- 
teni, mert a további lépések végrehajtása so- 
rán eltérő összesítéseket kapnánk a kiinduló 
állapothoz képest. 

A , Serializable" izolációs szinttel kell a 
legóvatosabban bánnunk. Alapszabály, hogy 
csak akkor alkalmazzuk, ha feltétlenül indo- 
kolt, és ebben az esetben minden lekérdezés 
minden feltételére megfelelő indexszel kell 
rendelkeznünk a táblazárak megakadályozá- 


sa érdekében. 


A , Read Committed Snapshot" 
izolációs szint 

A , Read Committed Snapshot" izolációs (rö- 
vidítve RCSD szinten futó tranzakciók az 
adatok olvasásakor mindig az olvasási műve- 
let indítása előtti utolsó konzisztens állapo- 
tot látják. Az RCSLt akkor használhatjuk, 
ha bekapcsoltuk a READ COMMIITED 
SNAPSHOT Ebben az 


esetben a , Read Committed" izolációs szint 


adatbázis-opciót. 


, Read Committed Snapshot" szintre vál 
tozik. (Minden RCI tranzakció RCSLként 
működik.) Az SOL Server a tranzakciókhoz 
ilyenkor egy folyamatosan növekvő tranzak- 
ció-azonosítót (XSN) rendel, és az egyes so- 
rok adatbázisba, illetve verziótárba írásakor 
a sort módosító tranzakció XSN/ét is kiírja. 
Ez nemcsak az RCSI tranzakciókra igaz, ha- 


nem minden adatmódosító tranzakcióra is. 
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Ha az RCSI tranzakció olyan adatot olvas- 
na, amelynek XSN-je nagyobb vagy egyenlő, 
mint az utasítás végrehajtásának indításakor 
aktív tranzakciók legkisebb XSN-Je (azaz a 
futó tranzakciók valamelyike módosította az 
adatot), akkor megkeresi a sornak azt a leg- 
frissebb változatát a verziótárban, amelynek 
az XSN/Jje kisebb ennél, és érvényesített tranz- 
akcióhoz tartozik, azaz az utasítás végrehaj- 
tása előtti legfiatalabb, még konzisztensnek 
tekinthető verziót. A nem RCSI tranzakciók 
(a , Snapshot" izolációs szintűek kivételével) 
nem használják a verziótárat az adateléréshez. 

Ha az RCSI tranzakció olyan adatot akát 
módosítani, amelyet egy másik futó tranzak- 
ció módosít, az RCSI tranzakciónak várnia 
kell a másik tranzakció befejeződésére. 

A READ COMMITTED SNAPSHOT 
adatbázis-opció bekapcsolásával tehát uta- 
sításszintű adatolvasási konzisztenciát érhe- 
tünk el anélkül, hogy más folyamatokat blok- 
kolnánk. Mivel az alkalmazások semmilyen 
módosítást nem igényelnek az RCSI haszná- 
latához, és az RCSI nem változtatja meg az 
egyidejű adatírás tiltására vonatkozó szigorú 
konzisztenciaszabályt sem, az alkalmazások 
túlnyomó többsége gond nélkül futtatható a 
READ COMMITTED SNAPSHOT adat 
bázis-tulajdonság beállításával. 

Mit nyerünk és mit veszítünk az RCSI 
használatával? A válasz egyszerű: nagyobb 
konkurenciát, kevesebb holtpontot kapunk, 
a teljesítmény csökkenése mellett. 

Az RCSI által okozott teljesítménycsök- 
kenés viszont sokkal jobban mérhető (ál 
talában néhány százalékos), kiszámítható, 
és könnyebben orvosolható, mint a túlzott 
blokkolás és a nehezen elemezhető, ad hoc 
módon jelentkező holtpontok által okozott 


teljesítménycsökkenés. 


A , Snapshot" izolációs szint 

A ,Snapshot" izolációs (rövidítve SI) szin- 
ten futó tranzakció az adatbázist mindig az 
elindulása előtti utolsó konzisztens állapot 
ban látja. SI. szintű tranzakciót csak akkor 
indíthatunk, ha bekapcsoltuk az , ALLOW 
SNAPSHOT ISOLATION" 
ciót minden olyan adatbázisban, amelyet a 
tranzakciónk használ. Az SOL Server ekkor 


az RCSI szint tárgyalásánál megismert azo- 


adatbázis-op- 


nosítóval (XSN) látja el a tranzakciókat. Ha 
az SI tranzakció olyan adatot olvasna, amely- 


nek XSN-Je nagyobb vagy egyenlő, mint az 


SI tranzakció indításakor aktív tranzakciók 
legkisebb XSN-je, akkor megkeresi a sornak 
azt a legelső változatát a verziótárban, amely- 
nek az XSN/je kisebb ennél, és érvényesített 
tranzakcióhoz tartozik, azaz a tranzakció in- 
dulása előtti legfiatalabb, még konzisztens- 
nek tekinthető verziót. A nem SI tranzak- 
ciók (az RCSI tranzakciók kivételével) nem 
használják a verziótárat az adateléréshez. 

A ,Snapshot" izolációs szint alkalmazása- 
kor, ha a tranzakció egy másik tranzakció ál- 
tal módosított adatot próbál írni, konfliktus 
keletkezik, mivel az SI tranzakció nem látja a 
sor aktuális állapotát, tehát feltehetőleg in- 
konzisztens állapot állna elő a módosításkor. 
Ezért az SI tranzakció ilyen esetben csak ad- 
dig vár, amíg a másik tranzakció véglegesítő- 
dik, majd hibával leáll, és visszagörgetődik. 
Ha a másik tranzakció visszagörgetődik, az 
SI tranzakció sikeresen végrehajthatja a mó- 
dosítást. Az SI tranzakció tehát rosszul viseli 
a konkurens írást, így abban az esetben, ha 
ennek nagy az esélye, szerencsésebb az RCSI 
vagy valamelyik pesszimista izolációs szint 
használata. 

Az SI tranzakció nem módosíthat táblát, 
indexet, adatbázist, és nem hozhat létre új 
indexet sem, továbbá osztott tranzakció-ke- 
zelésre sem használhatjuk. 

Kiválóan alkalmas viszont a pesszimista 
izolációs szintekben sok blokkolást okozó 
jelentéskészítő, lekérdező funkciók megva- 
lósítására, mivel biztosítja az adatkonziszten- 


ciát, és nem blokkolja az írási műveleteket. 


Milyen konkurenciakezelési 
modellt és milyen izolációs szintet 
válasszunk? 
Általánosságban azt mondhatjuk erre, hogy 
az online tranzakció-feldolgozó rendszerek 
(OLT P) esetében leginkább az RCI vagy az 
RCSI izolációs szintek használata javasolt, 
míg az SLt legjobban a lekérdező rendsze- 
rekben tudjuk kihasználni. A , Repeatable 
Read" és a , Serializable" izolációs szintek 
használatát csak olyan tranzakciók esetén ja- 
vasoljuk, ahol erősebb konzisztenciára van 
szükség. (A , Repeatable Read" gyakran ki- 
váltható SI-vel, azonban vigyázzunk: az SI 
nem garantálja azt, hogy más tranzakciók 
nem írják felül az adatokat, és nem tolerálja 
a konkurens adatmódosítást sem!) 
Amennyiben a rendszerünk jól működik 


a jelenleg alkalmazott pesszimista izolációs 





szintekkel, és csak időnként jelentkeznek 
hosszas várakozások, holtpontok, akkor cél 
szerűbb a problémák okát megkeresni és kija- 
vítani, mint vállalni az optimista RCSI vagy 
az SI által okozott teljesítménycsökkenést 
és az esetleges írási konfliktusok kezelését. 
Példa lehet erre egy jól megírt ügyviteli al 
kalmazás, ahol az egymással konkuráló fo- 
lyamatok gyakran okoznak rövid ideig fenn- 
álló blokkolást, de nem gyakran vezetnek 
holtpontokra. 

Az RCSI előnyét leginkább a nagy komp- 
lexitású, hosszan tartó tranzakciókat futtató 
vagy a konkurens hozzáférés szempontjából 
nem kellően átgondolt OLTP-rendszerek- 
nél lehet jól kihasználni. Mivel drasztiku- 
san tudjuk csökkenteni a zárak számát, és a 
zárolt adatokat is el tudjuk olvasni, az RCSI 
ebben az esetben ideális választás lehet. Az 
SI izolációs szint pedig legjobban azoknál az 
olvasásintenzív rendszereknél fizetődik ki, 
ahol az adatírások nem kerülnek egymással 
konfliktusba, vagy az SI tranzakció egyálta- 
lán nem ír adatot. 

Ilyen példa a lehet a folyamatosan frissí- 
tett, online lekérdezéseket támogató adattár- 
ház. Az adattárház folyamatos frissítése az SI 
alkalmazásával nem okoz gondot, mivel az SI 
lehetővé teszi az írások melletti konzisztens 
adatolvasást. 

Az OLT Prendszerekben az SI alkalmazá- 
sára a legjobb példa a jelentések futtatása. 
Ha a jelentést SI izolációs szinten indítjuk, 
akkor a jelentés futtatásának idejére nem 
blokkoljuk a felhasználókat, és mégis kon- 
zisztens adathalmazhoz jutunk. 

Az SI használatánál ne feledkezzünk meg 
az SI alkalmazási korlátairól sem: csak lo- 
kális tranzakciókban használhatjuk, bizo- 
nyos DDL-műveletek nem engedélyezettek, 
és az alkalmazásnak fel kell készülnie az írási 
konfliktusok kezelésére is. 

Tökéletes receptet nem tudunk adni arra 
vonatkozóan, hogy mikor melyik izolációs 
szintet érdemes alkalmazni, célszerű azon- 
ban itt is azt az elvet követni, hogy a lehetsé- 
ges megoldások közül általában a legegysze- 
rűbb a legjobb: használjuk az RCLt vagy az 
RCSLt, és csak akkor használjuk a többi izo- 
lációs szintet, ha feltétlenül szükséges. 

A cikkhez kapcsolódó példák a http:/www. 
szamalk.hu/tisza/sg12005 címről tölthetők le. 

Kovács Zoltán 
(kovacsz-Oszamalk.hu) vezető oktató, Számalk 
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Mit is csinál pontosan a magyarországi leányvállalat? 


Microsoft Magyarország Kft. a Microsoft Corporation magyarországi képviseleteként 
1993-ban alakult két fővel. Napjainkban a vállalat dolgozóinak létszáma eléri a 150 
főt. A magyar leányvállalat ügyvezető igazgatói tisztségét 2000 decembere óta Vityi 

Péter tölti be. 
A cég elsősorban kereskedelmi képviseletként működik, vagyis a Microsoft termékeit érté- 
kesíti hazai disztribútorokon és viszonteladó partnerein keresztül, valamint ehhez hasonlóan 


partnercégeket von be szolgáltatáskínálatának kiszélesítésére is. 


Ismét a legjobb hazai munkahely 
A Microsoft Magyarország nemcsak az informatikai élet területén tölt be vezető szerepet, ha- 
nem ugyanilyen kiemelkedő helyet foglal el a munkaadók között is. A Hewitt Inside kutató- 
cég és a Figyelő című gazdasági hetilap a 2003-as év , Legjobb munkahely tévé nyilvánította a 
Microsoft hazai leányvállalatát. 2006- 
ban ismét részt vettünk az ezúttal a 
Hewitt és a HVG által közösen meg- 
hirdetett felmérésben, és ismét első he- 


lyet értünk el. 


Részlegek és szakmai kihívások 
Joggal merülhet fel a kérdés az olvasó- 
ban, hogy informatikai szakemberként 
érdekes munkahely lehete a Microsoft 
Magyarország, vagy csak a konkrétter Adj 
mékfejlesztéssel foglalkozó központok: 
ban (például Redmondban) érdemes rövid vagy hosszú távon gondolkodni. Ahhoz, hogy be- 
mutassuk, milyen szakmai kihívásokat kínálunk a hazai szakembereknek, tekintsük át a cég 
felépítését. Jóllehet az egyes szervezeti egységekben más-más szakmai munka folyik, ami közös: 
az itt dolgozó szakemberek egy folyamatosan megújuló, innovatív cég tagjaként nagy önállóság 
mellett, izgalmas feladatokat végeznek. Ehhez minden munkaeszköz, képzés, és információ ren- 
delkezésükre áll. Az itt dolgozó szakemberek éves munkaidejük 10 százalékát képzéseken töltik, 
ami évi 20-25 nap hazai és nemzetközi tréninget jelent. 

Nagyvállalati szolgáltatások üzletág - MCS (Microsoft Consulting Services). Ez az üzletág 


a kiemelt ügyfeleknek segít a megvásárolt termékek bevezetésében, támogatásában, ezen belül 
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a konzulensek magas színvonalú informati- 
kai tanácsadással járulnak hozzá a projektek 
sikereihez. Az MCS-en belül egyaránt dolgoz- 
nak az ILinfrastruktúra kiépítésével, vala- 
mint szoftverfejlesztéssel és projektmenedzs- 
menttel foglalkozó szakemberek is. 

Ők az adott vállalat informatikai vezetésé- 
vel szorosan együttműködve biztosítják, hogy 
a már meglévő Microsoftszoftverek a lehető 
legjobban szolgálják az ügyfél konkrét infor 
matikai igényeit. Munkájuk során természe- 
tesen gyakran kapcsolatban állnak a szoftve- 
rek tényleges fejlesztőivel is: egyfelől visszajel- 
zéseikkel segítik a következő termékverziók 
minőségének és képességeinek további javí- 
tását, másrészt lehetőségük van mindenkinél 
korábban megismerni a még csak készülő, új 
szoftverek terveit, már működő verzióit. 

Innen már több kolléga is erősíti a red- 
mondi konzulensi csapatot, szívesen látják a 
külföldi csapatok a magyar tehetségeket. 

Nemzetközi terméktámogató központ - 
GISC (Global Technical Support Center). 
A Microsoft európai támogatóközpontjának 
szakemberei nagyvállalatok és Microsoft 
partnerek számára nyújtanak szakmai segít 
séget felmerülő problémáik orvoslására mind 
az üzemeltetés, mind a fejlesztés terén. A 
GTSC munkatársai nemcsak a magyar, ha- 
nem szinte valamennyi európai ügyféllel fog- 
lalkoznak, és munkájuk részeként - a kon- 
zulensekhez hasonlóan - napi kapcsolatban 


állnak a szoftverek fejlesztőivel is. 
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Fejlesztői platform üzletág - DPE (De- 
veloper áz Platform Evangelism). Ez az üz- 
letág felelős a fejlesztőeszközökkel és fejlesz- 
tőkkel kapcsolatos kommunikációért, vala- 
mint szintén az ő feladatuk a vállalatokkal 
szoros kapcsolatot ápoló, nagyszámú függet 
len szoftverfejlesztő segítése, ösztönzése. Az 
itt dolgozó szakemberek elsődleges feladata, 
hogy a vállalatok és a fejlesztői közösség szá- 
mára megmutassák a Microsoft fejlesztőesz- 
közeinek és teljes platformjának lehetőségeit, 
tényleges értékét, és ezzel együtt segítsék a 
fejlesztők mindennapi munkáját. Ennek ré- 
szeként - többek között - hozzájuk tartozik a 
teljes MSDN programsorozat is. 

Marketing - CMO (Central Marketing 
Organization). A marketing feladata az ér- 
tékesítés támogatása egyfelől azáltal, hogy 
kialakítja a megfelelő kommunikációs csa- 
tornákat, másfelől, hogy figyeli és elemzi a 
piaci és értékesítési trendeket, és ez alapján 
hangolja újra a későbbi kommunikációt. [de 
tartozik az IIrszakemberekkel folytatott szak- 
mai kommunikáció is (ez a TechNet), aminek 
elsődleges célja az II-szakemberek elégedett 
ségének és szakmai tudásának növelése. 

Nagyvállalati üzletág - EPG (Enterprise 
Sz Partner Group). A nagyvállalati üzlet 
ág foglalkozik a nagyobb méretű magyaror- 
szági vállalatokkal, beleértve a közületi fel 
használókat, közintézményeket, oktatási in- 
tézményeket és kormányzati hivatalokat is. 
Az ügyfelekkel dedikált ügyfélmenedzserek 
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Az év munkahelye — dolgozói party 


foglalkoznak, ők segítenek a vállalatoknak a 
számukra legmegfelelőbb informatikai meg- 
oldások megtalálásában. 

Ide tartozik még a nagyvállalati partnerek 
menedzsmentje is. Azonban ez sem csupán 


értékesítési tevékenység. Az üzletág részeként 


Pj! 





működik az a csapat, amelyik kifejezetten 
nagyvállatok számára mutatja be a legújabb 
technológiákat, és segít elkészíteni a nagyobb 
informatikai projektek rendszerterveit, pilot 
jait. Hosszú évek óta az ő nevükhöz kötőd- 
nek a TechNetesemények talán legjobb szak- 
mai előadásai is (a teljesség igénye nélkül, 
de itt dolgozik többek között Kőnig Tibor, 
Szalontay Zoltán és Koszó Károly is). 

Kis- és középvállalati üzletág - SMSSP 
(Small and Midsize Solutions Sz Partners). 


Le oz 


mutató: Microsoft - 90 százalék, magyar át 
lag - 48 százalék), és munkatársaink a legtöb- 
bet hozhassák ki magukból. Ehhez a HR-es 
stratégia 5 fő pilléren nyugszik: a teljesít 
ménymenedzsment, a bérezés és kiemelkedő 
juttatások, a szakmai fejlődés/karrier támo- 
gatása (hazai és nemzetközi tréningekkel), a 
jó vezetők és a kiváló munkakörülmények 
biztosítása. 

FSA 


(Finance áz Administration). A jól működő 


Pénzügy és adminisztráció - 





A Microsoft Magyarország szervezeti felépítése (nagy vonalakban) 


A kis- és középvállalkozásokra fókuszáló ke- 
reskedelmi egység; itt azonban az ügyfelek 
nagy száma miatt már nyilván nincs min- 
den egyes ügyfélhez saját ügyfélmenedzser. 
Viszont sokkal nagyobb hangsúlyt kap a ré- 
gió szerinti gondolkodás, valamint az érté- 
kesítési, megoldásszállító és oktatási partne- 
rek támogatása, fejlesztése. Itt is fokozatosan 
épül és növekszik egy, az EPG-nél ismertetett 
hez nagyban hasonlító szakmai csapat, ők el 
sősorban a partnerek szakmai továbbképzésé- 
ben vesznek részt. 
OEM-üzletág 


Eguipment Manutfacturer). 


(Original 


Nemrég vált önálló üzletág- 
gá. Ez a csapat kifejezetten az 
OEMrendszerépítőkre, vala- 
mint az áruházakra és a do- 
bozos szoftverek értékesítésé- 
re fókuszál. 

Emberi erőforrások - HR 
(Human Resources). A HR 
szerepe nagy jelentőségű egy 
olyan cég életében, ahol eny- 
nyi különböző szakterülettel 
és tapasztalattal rendelkező 
ember dolgozik közös célok érdekében. A 
HR azon kívül, hogy folyamatosan kutat a le- 
hető legjobb, leendő Microsoftmunkatársak 
után, azon fáradozik, hogy az itt dolgozók 
elkötelezettsége folyamatosan magas legyen 


(a Hewitt szerinti 2006-os elkötelezettségi 


cégnek ez a szervezet is fontos része. Szakmai 
szemmel itt az lehet érdekes, hogy ide tar 
tozik az a kéthárom fős ILcsapat is, akik a 
Microsoft Magyarország munkatársai számá- 
ra biztosítják a napi munkavégzéshez szüksé- 
ges informatikát. 

Ügyfélelégedettség - CPE (Customer 
and Partner Experience). A Microsoft ki 
emelt figyelmet szentel ügyfelei és partnerei 
elégedettségének javítására, véleményük meg- 
hallgatására. A CPE részleg elsősorban az ez- 
zel kapcsolatos feladatokat látja el, így többek 
között ők felügyelik és üzemeltetik a telefo- 


nos és e-mailes ügyfélszolgálatot is. 


Érdemes lehet körülnézni 

Akit mélyebben érdekel a munkánk, vagy 
szeretne többet tudni a cégről, nézzen körül 
blogjainkon. Egyre többen blogolunk, és a 
szakmai újdonságok mellett igyekszünk in- 
formációval szolgálni mindennapi munkánk: 
kal kapcsolatban is. Az egyik, amit érdemes 
lehet megnézni, az a nemrégiben hozzánk 
csatlakozott EPG-rendszermérnök, Lepenye 
Tamás webnaplója: a http://lepenyet.spaces. 
live.com címen érhető el. 

Akit pedig esetleg állásajánlatok érdekel 
nének a fent ismertetett részlegek bármelyi- 
kében, nézzen körül a http://www.microsoft. 
hu/allasajanlatok oldalon. 

Budai Péter 
(i-pbudai(oomicrosoft.com) Microsoft Magyarország 


Microsoft TechNet 








A MI FELTESSZÜK 
A BI-RE A PONTOT. 





LEGYEN ÖNNEK IS OLCSÓBB! 


Képzéscsomagjainkat 2007-ben 2099-kal olcsóbban 

keretszerződésben is megrendelheti. 

Keretszerződéses partnereink számára további 
BUSINESS INTELLIGENCE (BI) TANFOLYAMOK értéknövelt szolgáltatásokat nyújtunk: 


A NETACADEMIÁNÁL! 0 — Ingyenes tanfolyami utókövetés 
0 Ingyenes szaktanácsadás, 

A sikeresen működő vállalatok versenyképességének egyik egyedi konzultáció 
titka, hogy tudatosan használják, elemzik és értelmezik a 0 Ingyenes vizsgafelkészítő kit 
rendelkezésükre álló adatokat. 0 Ingyenes EU-pályázatíigyelés 
Az ehhez szükséges üzleti intelligencia (BI) technikai háttere és tanácsadás 
minden SOL Server vásárlónál elérhető, bevetésre készen áll, 
hisz benne van a termékben. A keretszerződéssel kapcsolatban keresse 
Itt az ideje, hogy használjuk is! Szántó Zoltánt 

KEN STR HALSBES E ; E-mail: 
BI-képzéseinken az alábbi kérdésekre adunk választ: SZANTO.ZOLTAN ONETACADEMIA.NET 


0 Mire használható egy többdimenziós OLAP kocka? 
0 Miként használható jól a Reporting Services 2005? 
0 Mik az újdonságai az Analysis Services 2005-nek? 
0 Mit csinál az Integration Services 2005? 


A képzések már elkezdődtek! 
2007-ben a NetAcademia szolgáltatja a hiányzó dimenziót. 


További információk: 
HTTPS://WWW.NETACADEMIA.NET/BI 


CÍM: 1062 BUDAPEST, ANDRÁSSY ÚT 62. 


TELEFON: (06 1) 472-1214 
IRODAI MOBIL: (06 20) 369-60947 
FAX: (06 1) 472-1215 


INTERNET: WWW.NETACADEMIA.NET 
E-MAIL: INFOGONETACADEMIA.NET 





ACADEMIA 


A LEGJOBBAKAT TANÍTJUK. 


Microsoft 





Készen állsz? 
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A szoftverekről szakmai információk a TechNet Portálon, a www.microsoft.hu/technet/launch oldalon, valamint 
a Microsoft weboldalán, a www.microsoft.hu/windowsvista és www.microsoft.hu/office2007 oldalakon találhatók. 





